Prd Authoring

PRD Authoring

<overview>

This skill provides comprehensive guidance for creating high-quality Product Requirement Documents (PRDs) that include:

• Complete technical specifications
• Actionable task lists with priorities
• Relevant code snippets and examples
• Clear implementation phases
• Measurable success criteria

</overview>

<quality_standards>

What Makes a Good PRD

A good PRD MUST be:

• Actionable: Each requirement can be implemented directly
• Complete: Covers functional, non-functional, and technical requirements
• Specific: Uses precise language, avoiding vague terms like "should" or "might"
• Measurable: Includes success metrics that can be quantified
• Implementable: Contains sufficient detail for engineering to build

Required Elements

Every PRD MUST include:

1. Problem Statement - Clear articulation of what problem we're solving and why 2. Goals - Specific, measurable objectives 3. Requirements - Functional and non-functional requirements 4. Architecture - System design, components, data flow 5. Implementation Plan - Phased approach with milestones 6. Task List - Actionable next steps (see template below) 7. Success Metrics - Quantifiable measures of success 8. Code Snippets - Relevant examples (see guidelines below)

</quality_standards>

<prd_template>

PRD Template

# [Feature Name] - PRD

## Overview
[2-3 sentence summary]

## Problem Statement
[What problem are we solving? Why now? What's the impact of not solving it?]

## Goals
- [ ] [Primary goal 1 - specific and measurable]
- [ ] [Primary goal 2 - specific and measurable]
- [ ] [Secondary goal 3]

## Non-Goals
[What we explicitly will NOT do in this iteration - sets scope boundaries]

## Requirements

### Functional Requirements
- [FR-1] [User stories/use cases as specific requirements]
- [FR-2] [Acceptance criteria for each requirement]

### Non-Functional Requirements
- [NFR-1] **Performance**: [specific metrics, e.g., "API responds in <200ms at p95"]
- [NFR-2] **Security**: [e.g., "All data encrypted at rest and in transit"]
- [NFR-3] **Scalability**: [e.g., "System handles 10k concurrent users"]
- [NFR-4] **Reliability**: [e.g., "99.9% uptime SLA"]

### Technical Requirements
- [TR-1] [Technology stack constraints]
- [TR-2] [Integration requirements]
- [TR-3] [Data retention/compliance requirements]

## Proposed Architecture

### System Design
[High-level architecture - use text diagrams or mermaid]

[Component A] ←→ [Component B] ←→ [Component C] ↓ ↓ ↓ [Database] [Cache Layer] [External API]

### Component Breakdown
- **Component A**: [Responsibility, technology choice, scaling approach]
- **Component B**: [Responsibility, technology choice, scaling approach]
- **Component C**: [Responsibility, technology choice, scaling approach]

### Data Flow
1. [Step-by-step description of how data moves through the system]
2. [Include error handling, retries, fallbacks]
3. [Describe async/sync boundaries]

### API Design (if applicable)
[Include endpoint specifications, request/response schemas]

## Technical Considerations

### Technology Choices
| Technology | Justification | Alternatives Considered |
|------------|---------------|-------------------------|
| [Tech 1]   | [Why this choice] | [Alternative 1, Alternative 2] |
| [Tech 2]   | [Why this choice] | [Alternative 1, Alternative 2] |

### Trade-offs Analyzed
| Option | Pros | Cons | Decision |
|--------|------|------|----------|
| [Option A] | ... | ... | ✅/❌ |
| [Option B] | ... | ... | ✅/❌ |

### Risks and Mitigations
| Risk | Impact | Probability | Mitigation Strategy |
|------|--------|-------------|---------------------|
| [Risk 1] | High/Med/Low | High/Med/Low | [How to address] |
| [Risk 2] | High/Med/Low | High/Med/Low | [How to address] |

## Implementation Strategy

### Phase 1: Foundation
- [ ] [Task 1.1]
- [ ] [Task 1.2]
- [ ] [Task 1.3]

**Definition of Done**: [Specific criteria for phase completion]

### Phase 2: Core Features
- [ ] [Task 2.1]
- [ ] [Task 2.2]
- [ ] [Task 2.3]

**Definition of Done**: [Specific criteria for phase completion]

### Phase 3: Polish & Launch
- [ ] [Task 3.1]
- [ ] [Task 3.2]
- [ ] [Task 3.3]

**Definition of Done**: [Specific criteria for phase completion]

## Task Breakdown

<task_list_template>
### High Priority (P0) - Blockers for launch
- [ ] **[TASK-1]**: [Actionable task title]
  - Complexity: [Simple/Medium/Complex]
  - Dependencies: [Task IDs or components that must exist first]
  - Parallelizable: [Yes/No - if Yes, specify which tasks can run simultaneously]
  - Testing: [Required/Recommended/None - specify type: unit, integration, e2e]
  - Acceptance criteria: [Specific, testable criteria]

### Medium Priority (P1) - Important but not blocking
- [ ] **[TASK-2]**: [Actionable task title]
  - Complexity: [Simple/Medium/Complex]
  - Dependencies: [Task IDs or components that must exist first]
  - Parallelizable: [Yes/No - if Yes, specify which tasks can run simultaneously]
  - Testing: [Required/Recommended/None - specify type: unit, integration, e2e]
  - Acceptance criteria: [Specific, testable criteria]

### Low Priority (P2) - Nice to have
- [ ] **[TASK-3]**: [Actionable task title]
  - Complexity: [Simple/Medium/Complex]
  - Dependencies: [Task IDs or components that must exist first]
  - Parallelizable: [Yes/No - if Yes, specify which tasks can run simultaneously]
  - Testing: [Required/Recommended/None - specify type: unit, integration, e2e]
  - Acceptance criteria: [Specific, testable criteria]
</task_list_template>

<parallelization_guidance>

### Task Parallelization

Mark tasks as **Parallelizable: Yes** when:
- Task is independent of other in-progress tasks
- Multiple developers/subagents can work on different aspects simultaneously
- Task can be split into independent sub-tasks

**Examples:**

✅ **Parallelizable**
- "Design REST API endpoints" and "Design database schema" - can be done simultaneously with coordination
- "Write frontend user profile component" and "Write frontend settings component" - independent components
- "Set up CI/CD pipeline" and "Set up monitoring infrastructure" - separate infrastructure tasks

❌ **Not Parallelizable**
- "Implement authentication" - blocks on "Design database schema" (dependency)
- "Write API tests" - requires API endpoints to exist first (dependency)

**Format for parallelizable tasks:**

• Parallelizable: Yes - Can run concurrently with [TASK-X], [TASK-Y]

</parallelization_guidance>

<complexity_guidance>

### Task Complexity Levels

**Simple**
- Well-defined scope
- No unknown unknowns
- Follows established patterns
- Single system/component
- Example: "Add email validation to registration form"

**Medium**
- Some research or investigation needed
- Multiple components to integrate
- Requires decision-making
- Some ambiguity to resolve
- Example: "Implement OAuth 2.0 login with Google and GitHub"

**Complex**
- Significant architectural decisions
- Cross-system dependencies
- High ambiguity or research required
- Performance or security concerns
- Requires prototyping or spikes
- Example: "Design and implement real-time notification system with WebSocket scaling"

</complexity_guidance>

<testing_guidance>

### Testing Requirements

Each task MUST specify testing needs:

**Required** - Critical functionality, MUST have tests before merging
- User authentication/authorization
- Payment processing
- Data persistence operations
- External API integrations

**Recommended** - Should have tests but not blocking
- UI components
- Business logic validation
- Edge case handling
- Error scenarios

**None** - Tests not applicable
- Configuration changes
- Documentation updates
- Infrastructure setup
- Design/mockup tasks

**Test Types:**
- `unit` - Individual functions/components in isolation
- `integration` - Multiple components working together
- `e2e` - Full user flows from start to finish
- `performance` - Load testing, benchmarks
- `security` - Penetration testing, vulnerability scans

</testing_guidance>

## Success Metrics
- [Metric 1]: [Current value] → [Target value]
- [Metric 2]: [Current value] → [Target value]
- [Metric 3]: [Current value] → [Target value]

## Open Questions
- [Q1] [Question that needs resolution]
  - Options: [Option A, Option B, Option C]
  - Decision owner: [Who will decide]

## Appendices

### Code Snippets
[Include relevant code examples - see guidelines below]

### Data Schemas
[Include database schemas, type definitions, etc.]

### Mockups
[Links to UI mockups or wireframes]

</prd_template>

<code_snippet_guidelines>

When to Include Code Snippets

PRDs SHOULD include code snippets when they clarify technical details. Use for:

1. API Design

Include when: Defining endpoints, request/response formats

// POST /api/users
interface CreateUserRequest {
  email: string;
  password: string; // Hashed with bcrypt
  name: string;
}

interface CreateUserResponse {
  id: string;
  email: string;
  createdAt: Date;
}

2. Data Schemas

Include when: Defining database models, type definitions

// User schema
interface User {
  id: string; // UUID
  email: string; // Unique, indexed
  passwordHash: string; // bcrypt
  createdAt: Date;
  updatedAt: Date;
}

// Indexes
db.users.createIndex({ email: 1 }, { unique: true });

3. Configuration Examples

Include when: Defining feature flags, environment variables

# Environment variables
DATABASE_URL=postgresql://...
JWT_SECRET=your-secret-key
RATE_LIMIT_ENABLED=true
RATE_LIMIT_REQUESTS_PER_MINUTE=100

4. Algorithm Examples

Include when: Explaining complex logic

// Rate limiting algorithm
function rateLimit(userId: string): boolean {
  const requests = redis.get(`ratelimit:${userId}`) || 0;
  if (requests >= LIMIT) {
    return false; // Rate limited
  }
  redis.incr(`ratelimit:${userId}`);
  redis.expire(`ratelimit:${userId}`, 60);
  return true; // Allowed
}

5. Integration Examples

Include when: Showing how components interact

// Example: Service A calling Service B
const response = await fetch('http://service-b/api/process', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ data: payload })
});

What NOT to Include

❌ Full implementation code - PRDs are for requirements, not implementation ❌ Business logic details - Save for actual development ❌ Boilerplate code - Unless it's configuration

✅ DO include: Interfaces, schemas, examples of architecture ✅ DO include: Configuration, API contracts, data models

</code_snippet_guidelines>

<task_list_guidelines>

Creating Actionable Task Lists

Tasks in PRDs MUST be:

Specific

❌ "Implement user authentication" ✅ "Implement OAuth 2.0 login with Google and GitHub providers"

Testable

❌ "Make it fast" ✅ "API response time <200ms at p95 under 1000 RPS"

Atomic

❌ "Build the entire checkout flow" ✅ "Build cart summary endpoint" (one of many tasks)

Testable

Each task MUST specify testing requirements (Required/Recommended/None)

Task Template (AI-Agent Optimized)

- [ ] **[TASK-ID]** [Actionable title]
  - **Complexity**: [Simple/Medium/Complex]
  - **Dependencies**: [Task IDs or components that must exist first]
  - **Parallelizable**: [Yes/No - if Yes, specify which tasks]
  - **Testing**: [Required/Recommended/None - specify type: unit, integration, e2e]
  - **Acceptance Criteria**:
    - [ ] [Criterion 1 - must be testable]
    - [ ] [Criterion 2 - must be testable]

</task_list_guidelines>

<anti_patterns>

Common PRD Anti-Patterns

Vague Language

❌ "The system should be scalable" ✅ "System must handle 10,000 concurrent users with <500ms response time"

Missing Acceptance Criteria

❌ "Implement search functionality" ✅ "Implement full-text search with filters, returning results in <100ms, supporting 100+ concurrent searches"

No Success Metrics

❌ "Improve user engagement" ✅ "Increase daily active users from 1,000 to 2,000 within 90 days"

Infinite Scope

❌ "Build the best e-commerce platform" ✅ "Build MVP with product catalog, cart, and checkout (payments via Stripe)"

Missing Technical Details

❌ "Use a database" ✅ "Use PostgreSQL for relational data, Redis for caching, with proper indexing on email and product_id"

No Risk Assessment

❌ [No risk section] ✅ [Include risks table with mitigations]

</anti_patterns>

<workflow>

PRD Authoring Workflow

1. Understand the Problem

• Interview stakeholders if needed
• Identify pain points with current solution
• Quantify the opportunity

2. Draft Requirements

• Start with user stories
• Convert to functional requirements (FR-1, FR-2, etc.)
• Add non-functional requirements (NFR-1, NFR-2, etc.)

3. Design Architecture

• Create system diagram
• Define components and their responsibilities
• Map data flow between components

4. Add Technical Details

• Choose technologies with justification
• Document trade-offs
• Include relevant code snippets

5. Create Task Breakdown

• Break into phases
• Create specific, actionable tasks
• Identify dependencies

6. Define Success

• Set measurable metrics
• Define baseline and target

7. Review and Refine

• Check against quality standards
• Ensure no anti-patterns
• Validate with stakeholders

</workflow>

<examples>

See references/examples.md for complete PRD examples.

</examples>

PRD Examples

This file contains complete PRD examples demonstrating the quality standards and templates from SKILL.md.

<example_rest_api>

Example 1: REST API for Task Management

# Task Management API - PRD

## Overview
Build a RESTful API for managing tasks and projects, enabling teams to create, assign, track, and complete work items with support for due dates, priorities, and comments.

## Problem Statement
Teams currently manage tasks through spreadsheets and email, leading to:
- Lost or forgotten tasks (15% of tasks never completed)
- No visibility into project status
- Difficulty tracking who is doing what
- No audit trail of task changes

We need a centralized, reliable task management system.

## Goals
- Reduce task fall-through rate from 15% to <2% within 90 days
- Enable real-time task status visibility for all team members
- Support teams of 1-100 people
- Achieve 99.9% uptime SLA

## Non-Goals
- Time tracking functionality (Phase 2)
- Git integration (Phase 2)
- Mobile apps (Phase 2 - MVP is web-only)
- Advanced reporting/analytics (Phase 2)

## Requirements

### Functional Requirements
- [FR-1] Users MUST be able to create tasks with title, description, due date, priority (low/medium/high), and assignee
- [FR-2] Users MUST be able to update task status (todo/in_progress/done)
- [FR-3] Users MUST be able to add comments to tasks
- [FR-4] Users MUST be able to filter tasks by project, assignee, status, and priority
- [FR-5] Users MUST be able to assign tasks to other users
- [FR-6] System MUST send email notifications for task assignments and due date reminders

### Non-Functional Requirements
- [NFR-1] **Performance**: API MUST respond in <200ms at p95 for all endpoints
- [NFR-2] **Scalability**: System MUST support 10,000 concurrent users
- [NFR-3] **Reliability**: 99.9% uptime SLA (max 43 minutes downtime/month)
- [NFR-4] **Security**: All endpoints MUST require authentication except /health
- [NFR-5] **Security**: Passwords MUST be hashed with bcrypt (cost factor 12)
- [NFR-6] **Data Retention**: Deleted tasks MUST be soft-deleted for 30 days

### Technical Requirements
- [TR-1] API MUST follow REST conventions (proper HTTP verbs, status codes)
- [TR-2] All write operations MUST be idempotent where possible
- [TR-3] System MUST use PostgreSQL for data persistence
- [TR-4] System MUST use Redis for caching frequently-accessed tasks

## Proposed Architecture

### System Design

[Client] ←→ [Load Balancer] ←→ [API Server (Node.js)] ↓ [PostgreSQL Database] ↓ [Redis Cache Layer]

### Component Breakdown

**API Server (Node.js/Express)**
- Responsibilities: Request handling, authentication, business logic
- Scaling: Horizontal scaling via stateless design
- Technology: Node.js 20 LTS, Express.js

**PostgreSQL Database**
- Responsibilities: Persistent data storage
- Scaling: Read replicas for queries, primary for writes
- Technology: PostgreSQL 16

**Redis Cache**
- Responsibilities: Cache frequently-accessed tasks and user sessions
- Scaling: Redis Cluster for horizontal scaling
- Technology: Redis 7

### Data Flow

1. **Create Task Flow**
   - Client POSTs to `/api/tasks` with task data
   - API validates request (authentication, input validation)
   - API writes task to PostgreSQL
   - API caches task in Redis (TTL 5 minutes)
   - API returns 201 with created task
   - API sends email notification to assignee (async queue)

2. **Get Task Flow**
   - Client GETs `/api/tasks/:id`
   - API checks Redis cache first
   - If cache hit: return cached task (sub-1ms response)
   - If cache miss: query PostgreSQL, cache result, return task

### API Design

<code_snippets>

#### Endpoints

// Task Endpoints

// Create task POST /api/tasks Authorization: Bearer <token> Content-Type: application/json

{ "title": "Implement login", "description": "Add OAuth login with Google", "dueDate": "2024-02-15T10:00:00Z", "priority": "high", "assigneeId": "user-123" }

Response: 201 Created { "id": "task-456", "title": "Implement login", "description": "Add OAuth login with Google", "status": "todo", "dueDate": "2024-02-15T10:00:00Z", "priority": "high", "assignee": { "id": "user-123", "name": "Jane Doe", "email": "jane@example.com" }, "createdAt": "2024-01-15T10:00:00Z", "updatedAt": "2024-01-15T10:00:00Z" }

// Get task GET /api/tasks/:id Response: 200 OK (task object)

// Update task PATCH /api/tasks/:id Body: { status: "in_progress" } Response: 200 OK (updated task)

// List tasks GET /api/tasks?assignee=user-123&status=todo&priority=high Response: 200 OK { "tasks": [...], "total": 42, "page": 1, "pageSize": 20 }

// Add comment POST /api/tasks/:id/comments Body: { "content": "This is blocked on design review" } Response: 201 Created

#### Data Schemas

// Database schema

// Tasks table interface Task { id: string; // UUID title: string; // varchar(255), NOT NULL description: string; // text status: 'todo' | 'in_progress' | 'done'; // enum, DEFAULT 'todo' priority: 'low' | 'medium' | 'high'; // enum, DEFAULT 'medium' dueDate: Date | null; // timestamp assigneeId: string | null; // UUID FK → users.id projectId: string; // UUID FK → projects.id, NOT NULL createdAt: Date; // timestamp, DEFAULT NOW() updatedAt: Date; // timestamp, DEFAULT NOW() deletedAt: Date | null; // timestamp, for soft delete }

// Comments table interface Comment { id: string; // UUID taskId: string; // UUID FK → tasks.id, NOT NULL authorId: string; // UUID FK → users.id, NOT NULL content: string; // text, NOT NULL createdAt: Date; // timestamp, DEFAULT NOW() }

// Indexes CREATE INDEX idx_tasks_assignee ON tasks(assigneeId) WHERE deletedAt IS NULL; CREATE INDEX idx_tasks_project ON tasks(projectId) WHERE deletedAt IS NULL; CREATE INDEX idx_tasks_status ON tasks(status) WHERE deletedAt IS NULL; CREATE INDEX idx_comments_task ON comments(taskId);

#### Configuration

Environment variables

DATABASE_URL=postgresql://user:pass@localhost:5432/taskdb REDIS_URL=redis://localhost:6379 JWT_SECRET=prod-secret-key-change-me JWT_EXPIRES_IN=24h SMTP_HOST=smtp.sendgrid.net SMTP_API_KEY=SG.xxx

</code_snippets>

## Technical Considerations

### Technology Choices

| Technology | Justification | Alternatives Considered |
|------------|---------------|-------------------------|
| Node.js/Express | Team expertise, great async I/O, fast development | Python/FastAPI (considered), Go (too complex for team) |
| PostgreSQL | ACID compliance, complex queries, JSON support | MySQL (considered), MongoDB (lacks transaction support) |
| Redis | Sub-millisecond reads, mature ecosystem | Memcached (no persistence), In-memory cache (built-in, slower) |
| JWT | Stateless auth, widely supported | Sessions (requires session store) |

### Trade-offs Analyzed

| Option | Pros | Cons | Decision |
|--------|------|------|----------|
| SQL vs NoSQL | SQL: ACID, complex queries; NoSQL: Flexible schema | NoSQL lacks transaction support for task+comment atomicity | ✅ SQL (PostgreSQL) |
| REST vs GraphQL | REST: Simple, cacheable; GraphQL: Flexible queries | GraphQL adds complexity, overkill for CRUD API | ✅ REST |
| Monolith vs Microservices | Monolith: Simple deploy; Microservices: Scalable | Microservices add operational complexity | ✅ Monolith (can extract services later) |

### Risks and Mitigations

| Risk | Impact | Probability | Mitigation Strategy |
|------|--------|-------------|---------------------|
| Database becomes bottleneck | High | Medium | Add Redis cache, implement read replicas, database connection pooling |
| Cache stampede (thundering herd) | High | Low | Implement request coalescing, use cache locks |
| Authentication service down | High | Low | Use stateless JWT (no session store), implement retry with exponential backoff |
| Email delivery delays | Medium | Medium | Use message queue (SQS/Redis Queue) for async sending |
| SQL injection | Critical | Low | Use parameterized queries (ORM), input validation, rate limiting |

## Implementation Strategy

### Phase 1: Foundation
- [ ] **TASK-1**: Set up project structure and development environment
  - Complexity: Simple
  - Dependencies: None
  - Parallelizable: Yes - Can run concurrently with infrastructure setup (TASK-8 early stages)
  - Testing: Recommended - integration tests for CI/CD pipeline
  - Acceptance criteria: Repo created, CI/CD pipeline working, local dev setup documented

- [ ] **TASK-2**: Design and implement database schema with migrations
  - Complexity: Medium
  - Dependencies: TASK-1
  - Parallelizable: Yes - Schema design can begin during TASK-1, coordinate on final structure
  - Testing: Required - integration tests for migrations, schema validation
  - Acceptance criteria: Migration scripts tested, schema matches API design

- [ ] **TASK-3**: Implement authentication endpoints (register, login, logout)
  - Complexity: Medium
  - Dependencies: TASK-2
  - Parallelizable: No - Requires database schema to be finalized
  - Testing: Required - unit tests for password hashing, integration tests for auth flow
  - Acceptance criteria: JWT tokens work, password hashing with bcrypt, tests pass

**Definition of Done**: Authentication system functional, database schema finalized, API framework ready

### Phase 2: Core CRUD
- [ ] **TASK-4**: Implement task CRUD endpoints (create, read, update, delete)
  - Complexity: Medium
  - Dependencies: TASK-3
  - Parallelizable: Yes - Can split into subtasks (create, read, update, delete) worked in parallel
  - Testing: Required - unit tests for each endpoint, integration tests for full CRUD flow
  - Acceptance criteria: All endpoints working, integration tests pass, p95 <200ms

- [ ] **TASK-5**: Implement task filtering and pagination
  - Complexity: Medium
  - Dependencies: TASK-4
  - Parallelizable: Yes - Can work on filtering logic separately from pagination logic
  - Testing: Required - integration tests for various filter combinations, edge cases
  - Acceptance criteria: Query builder supports all filter combinations, performance validated

- [ ] **TASK-6**: Implement comment system
  - Complexity: Simple
  - Dependencies: TASK-4
  - Parallelizable: Yes - Independent from TASK-5, can run concurrently
  - Testing: Required - unit tests for comment operations, integration tests with tasks
  - Acceptance criteria: Comments CRUD works, notification system integrated

**Definition of Done**: Task and comment management fully functional with caching

### Phase 3: Polish & Launch
- [ ] **TASK-7**: Implement email notifications (assignment, due date reminders)
  - Complexity: Medium
  - Dependencies: TASK-6
  - Parallelizable: No - Depends on comment system for assignment notifications
  - Testing: Required - integration tests with email queue, e2e tests for notification delivery
  - Acceptance criteria: Emails sent reliably via queue system, templates tested

- [ ] **TASK-8**: Add rate limiting and abuse prevention
  - Complexity: Simple
  - Dependencies: TASK-4
  - Parallelizable: Yes - Independent task, can run with other P2 tasks
  - Testing: Required - integration tests for rate limit enforcement, edge cases
  - Acceptance criteria: Rate limits enforced (100 req/min per user), abuse alerts working

- [ ] **TASK-9**: Performance testing and optimization
  - Complexity: Complex
  - Dependencies: All tasks
  - Parallelizable: Yes - Can split into database optimization, caching strategy, query tuning
  - Testing: Required - performance tests, load tests, benchmarking
  - Acceptance criteria: p95 <200ms at 1000 RPS, load test report generated

- [ ] **TASK-10**: Security audit and penetration testing
  - Complexity: Complex
  - Dependencies: All tasks
  - Parallelizable: Yes - Can run in parallel with TASK-9
  - Testing: Required - security tests, vulnerability scans, penetration testing
  - Acceptance criteria: No critical vulnerabilities found, fixes deployed for any issues

**Definition of Done**: Production-ready API with monitoring, logging, and security measures

## Task Breakdown

### High Priority (P0) - Blockers for launch
- [ ] **TASK-1**: Project setup and dev environment
  - Complexity: Simple
  - Dependencies: None
  - Parallelizable: Yes - Can run simultaneously with infrastructure setup
  - Testing: Recommended - integration tests for CI/CD pipeline
  - Acceptance criteria: Repo exists, README documents local setup, CI/CD pipeline deploys to staging

- [ ] **TASK-2**: Database schema and migrations
  - Complexity: Medium
  - Dependencies: TASK-1
  - Parallelizable: Yes - Schema design can begin during TASK-1, coordinate on final structure
  - Testing: Required - integration tests for migrations, schema validation
  - Acceptance criteria: `migrations/` folder has up/down scripts, tests verify schema

- [ ] **TASK-3**: Authentication system
  - Complexity: Medium
  - Dependencies: TASK-2
  - Parallelizable: No - Requires database schema to be finalized
  - Testing: Required - unit tests for password hashing, integration tests for auth flow
  - Acceptance criteria: POST /auth/register and /auth/login work, returns valid JWT

- [ ] **TASK-4**: Task CRUD endpoints
  - Complexity: Medium
  - Dependencies: TASK-3
  - Parallelizable: Yes - Can split into subtasks (create, read, update, delete) worked in parallel
  - Testing: Required - unit tests for each endpoint, integration tests for CRUD flow
  - Acceptance criteria: POST/GET/PATCH/DELETE /api/tasks work with valid data

### Medium Priority (P1) - Important but not blocking
- [ ] **TASK-5**: Filtering and pagination
  - Complexity: Medium
  - Dependencies: TASK-4
  - Parallelizable: Yes - Can work on filtering logic separately from pagination logic
  - Testing: Required - integration tests for various filter combinations
  - Acceptance criteria: Query string parameters work, pagination metadata correct

- [ ] **TASK-6**: Comment system
  - Complexity: Simple
  - Dependencies: TASK-4
  - Parallelizable: Yes - Independent from TASK-5, can run concurrently
  - Testing: Required - unit tests for comment operations, integration tests with tasks
  - Acceptance criteria: Comments can be added to tasks, returned with task details

- [ ] **TASK-7**: Email notifications
  - Complexity: Medium
  - Dependencies: TASK-6
  - Parallelizable: No - Depends on comment system for assignment notifications
  - Testing: Required - integration tests with email queue, e2e tests for delivery
  - Acceptance criteria: Emails sent on assignment and due date, queue system working

### Low Priority (P2) - Nice to have
- [ ] **TASK-8**: Rate limiting
  - Complexity: Simple
  - Dependencies: TASK-4
  - Parallelizable: Yes - Independent task, can run with other P2 tasks
  - Testing: Required - integration tests for rate limit enforcement
  - Acceptance criteria: 429 responses after limit, headers show rate limit info

- [ ] **TASK-9**: Performance optimization
  - Complexity: Complex
  - Dependencies: All tasks
  - Parallelizable: Yes - Can split into database optimization, caching strategy, query tuning
  - Testing: Required - performance tests, load tests, benchmarks
  - Acceptance criteria: Redis caching implemented, benchmarks show improvement

## Success Metrics
- **Task completion rate**: 85% → 98% within 90 days (measure: tasks marked as "done" / tasks created)
- **API response time**: p95 <200ms (measure: API gateway metrics)
- **System uptime**: 99.9% (measure: monitoring service uptime)
- **User adoption**: 50 team members using the system within 30 days (measure: user count in DB)

## Open Questions
- **Q1**: Should we support task dependencies (task B blocks task A)?
  - Options: (a) Yes, add in Phase 1, (b) Defer to Phase 2, (c) Not needed
  - Decision needed by: 2024-01-20
  - Owner: Product Manager
  - **Decision**: Defer to Phase 2 (focus on core CRUD first)

- **Q2**: Real-time updates for task status changes?
  - Options: (a) WebSocket push, (b) Polling, (c) No real-time needed
  - Decision needed by: 2024-01-20
  - Owner: Tech Lead
  - **Decision**: Defer to Phase 2 (Phase 1 uses polling every 30s)

## Appendices

### Monitoring Setup

// Metrics to track const metrics = { // Request metrics 'api.request.count': Counter for all API requests, 'api.request.duration': Histogram for response times, 'api.request.errors': Counter for 4xx/5xx responses,

// Business metrics 'tasks.created': Counter for tasks created, 'tasks.completed': Counter for tasks marked done, 'users.active': Gauge for active users (last 24h),

// Infrastructure metrics 'db.connections': Gauge for PostgreSQL pool usage, 'cache.hit_rate': Gauge for Redis cache effectiveness, };

// Alerting rules

• Alert if api.request.duration p95 >200ms for 5 minutes
• Alert if api.request.errors >5% for 5 minutes
• Alert if tasks.created = 0 for 1 hour (indicates issue)

</example_rest_api>

---

Quality Checklist Applied:

• ✅ Specific, measurable goals
• ✅ Functional and non-functional requirements numbered
• ✅ System design diagram
• ✅ Data flow with steps
• ✅ Code snippets (API endpoints, schemas, config)
• ✅ Technology choices justified
• ✅ Trade-offs analyzed
• ✅ Risk mitigation table
• ✅ Phased implementation with tasks
• ✅ Tasks include complexity, parallelization, and testing requirements
• ✅ Success metrics with baselines and targets
• ✅ Open questions with options and owners