#Plan Tasks

Generate detailed task files from a PRD. Creates task files in the PRD folder with BDD scenarios, implementation checklists, and pseudocode. Updates PRD.md with task links.

#Workflow

You are a senior frontend architect creating detailed, implementable task files from a PRD.

#Step 1: Find and Read the PRD

Find PRD folders in prds/:

Glob prds/*/PRD.md

If multiple PRDs exist, ask the user which one to use. Then read the selected PRD.

#Step 2: Understand the Existing Codebase

Before planning, explore the codebase to understand:

• Current project structure
• Existing components, repositories, use cases, or other pieces that can be reused
• Existing feature implementations
• UI components available (explore src/core/shared-core)

Important: Read the DDD Architecture Patterns section in CLAUDE.md for:

• Layer structure and dependency rules
• DI Container Registration pattern
• Mother Pattern for test data
• TDD Enforcement requirements
• Skill auto-chain order

#Step 3: Ask Clarifying Questions

Use AskUserQuestion to clarify ambiguities:

• Priorities: Which features are MVP vs. nice-to-have?
• Technical decisions: Any preferences on libraries or approaches?
• Scope: Any features that should be deferred?
• Dependencies: External services or APIs not clear in the PRD?
• Existing code: Reuse/refactor existing code or start fresh?

Continue asking until you have complete clarity.

#Step 4: Design Task Breakdown

Break down the PRD into phases and tasks following these rules:

TDD-First Philosophy:

• Every task starts with tests (via /tdd-bdd)
• Tests must FAIL before implementation begins
• Implementation makes tests GREEN
• This is enforced by /code-task

Baby Step Philosophy:

• Each task MUST be small enough to complete with all checks passing
• After EVERY task: validate the project with /architecture-guardrails
• No task should break the build, even temporarily

Logical Dependencies (following skill chain order):

1. Tests first (always)
2. Domain layer before application layer
3. Application layer before infrastructure
4. Infrastructure before delivery (UI)

Typical Phase Structure:

1. Phase 1: Foundation — Tests + Domain entities, value objects
2. Phase 2: Application — Tests + Use cases (queries/commands)
3. Phase 3: Infrastructure — Tests + Repositories, adapters
4. Phase 4: Delivery — Tests + UI pages, components, hooks
5. Phase 5: Polish — Error handling, edge cases, a11y

#Step 5: Create Task Files

For each task, create a detailed file in prds/[prd-folder]/tasks/:

Filename format: [phase].[task]-[kebab-name].md

• Example: 1.1-create-asset-entity.md
• Example: 2.3-implement-search-query.md

Task file structure:

# Task [X.Y]: [Task Name]

**Phase**: [Phase Name]
**Status**: ⬜ Not Started
**Dependencies**: [List task codes this depends on, or "None"]

---

## Overview

[2-3 sentences describing what this task accomplishes]

**🔴 Before**: [Current state before this task]
**🟢 After**: [Expected state after this task]

---

## BDD Scenarios

### Scenario 1: [Happy path name]
\`\`\`gherkin
Given [precondition]
When [action]
Then [expected outcome]
\`\`\`

### Scenario 2: [Edge case or error]
\`\`\`gherkin
Given [precondition]
When [action]
Then [expected outcome]
\`\`\`

---

## Implementation Checklist

### Tests (FIRST — via /tdd-bdd)
- [ ] `src/features/<feature>/**/*.test.unit.ts` — Domain/application tests
- [ ] `src/features/<feature>/**/*.it.test.tsx` — Integration tests
- [ ] `e2e-tests/<feature>.test.e2e.ts` — E2E tests (if UI)

### Domain Layer
- [ ] `src/features/<feature>/domain/<file>.ts` — [purpose]
- [ ] `src/features/<feature>/domain/<entity>.mother.ts` — Test data factory

### Application Layer
- [ ] `src/features/<feature>/application/<file>.ts` — [purpose]

### Infrastructure Layer
- [ ] `src/features/<feature>/infrastructure/<file>.ts` — [purpose]

### Delivery Layer
- [ ] `src/features/<feature>/delivery/<file>.tsx` — [purpose]

### DI Registration
- [ ] `src/core/di/injection-token.ts` — Add repository token
- [ ] `src/core/di/app.container.ts` — Register repository and use cases

---

## Files to Create/Modify

### `path/to/file.ts`

**Purpose**: [What this file does]
**Scenario**: [Which BDD scenario this implements]

\`\`\`typescript
// Pseudocode — detailed enough for mechanical implementation
\`\`\`

---

## Architecture Gate

Before marking complete, verify:
- [ ] TDD: Tests written FIRST, then implementation
- [ ] No framework imports in domain layer
- [ ] No business logic in delivery layer
- [ ] Dependencies flow inward (delivery → application → domain)
- [ ] DI registration complete (see CLAUDE.md pattern)
- [ ] All tests pass (`npm run test`)
- [ ] Lint passes (`npm run lint`)
- [ ] Types valid (`npm run compile`)
- [ ] Build passes (`npm run build`)

---

## Notes

[Any additional context, gotchas, or decisions made during planning]

#Step 6: Update PRD with Task Links

After creating all task files, update the PRD.md Tasks section:

## Tasks

| # | Task | Description | Dependencies | Status |
|---|------|-------------|--------------|--------|
| 1.1 | [Task Name](tasks/1.1-task-name.md) | Brief description | None | ⬜ |
| 1.2 | [Task Name](tasks/1.2-task-name.md) | Brief description | 1.1 | ⬜ |
| 2.1 | [Task Name](tasks/2.1-task-name.md) | Brief description | 1.2 | ⬜ |

**Status Legend**: ⬜ Not Started | 🔄 In Progress | ✅ Complete | ⏸️ Blocked

---

## Implementation Order

Recommended sequence (TDD-first):
1. Task 1.1 — [Name] (tests → implementation)
2. Task 1.2 — [Name] (tests → implementation)
3. Task 2.1 — [Name] (tests → implementation)
...

---

## Risk Mitigation

| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk] | High/Med/Low | [How to mitigate] |

#Step 7: Summary

After creating all files, output a summary:

✅ Planning complete for: [PRD Name]

📁 PRD Folder: prds/YYYY-MM-DD_type_name/
📄 Tasks created: [count]

Phase 1: [Name] ([count] tasks)
  - 1.1 [Task name]
  - 1.2 [Task name]

Phase 2: [Name] ([count] tasks)
  - 2.1 [Task name]
  ...

Workflow:
1. Start with Task 1.1
2. Run /code-task (enforces TDD gate)
3. Skill chain: /tdd-bdd → /create-domain-model → ... → /refactor
4. Mark tasks complete as you finish them

#Rules

1. TDD-first — Every task assumes tests are written first
2. One task = one green build — Never create tasks that leave the build broken
3. Tests included — Every task's checklist starts with test files
4. Pseudocode quality — Detailed enough that implementation is mechanical
5. BDD required — Every task must have Given/When/Then scenarios
6. Architecture gate — Every task verifies clean architecture rules
7. Dependencies explicit — Task files clearly state what must be done first
8. Skill chain aware — Tasks align with the skill chain order in CLAUDE.md