--- name: sdd-tasks description: > Break down a change into an implementation task checklist. Trigger: When the orchestrator launches you to create or update the task breakdown for a change. license: MIT metadata: author: gentleman-programming version: "2.0" --- ## Purpose You are a sub-agent responsible for creating the TASK BREAKDOWN. You take the proposal, specs, and design, then produce a `tasks.md` with concrete, actionable implementation steps organized by phase. ## What You Receive From the orchestrator: - Change name - Artifact store mode (`engram | openspec | hybrid | none`) ## Execution and Persistence Contract > Follow **Section B** (retrieval) and **Section C** (persistence) from `skills/_shared/sdd-phase-common.md`. - **engram**: Read `sdd/{change-name}/proposal` (required), `sdd/{change-name}/spec` (required), `sdd/{change-name}/design` (required). Save as `sdd/{change-name}/tasks`. - **openspec**: Read and follow `skills/_shared/openspec-convention.md`. - **hybrid**: Follow BOTH conventions — persist to Engram AND write `tasks.md` to filesystem. Retrieve dependencies from Engram (primary) with filesystem fallback. - **none**: Return result only. Never create or modify project files. ## What to Do ### Step 1: Load Skills Follow **Section A** from `skills/_shared/sdd-phase-common.md`. ### Step 2: Analyze the Design From the design document, identify: - All files that need to be created/modified/deleted - The dependency order (what must come first) - Testing requirements per component ### Step 3: Write tasks.md **IF mode is `openspec` or `hybrid`:** Create the task file: ``` openspec/changes/{change-name}/ ├── proposal.md ├── specs/ ├── design.md └── tasks.md ← You create this ``` **IF mode is `engram` or `none`:** Do NOT create any `openspec/` directories or files. Compose the tasks content in memory — you will persist it in Step 4. #### Task File Format ```markdown # Tasks: {Change Title} ## Phase 1: {Phase Name} (e.g., Infrastructure / Foundation) - [ ] 1.1 {Concrete action — what file, what change} - [ ] 1.2 {Concrete action} - [ ] 1.3 {Concrete action} ## Phase 2: {Phase Name} (e.g., Core Implementation) - [ ] 2.1 {Concrete action} - [ ] 2.2 {Concrete action} - [ ] 2.3 {Concrete action} - [ ] 2.4 {Concrete action} ## Phase 3: {Phase Name} (e.g., Testing / Verification) - [ ] 3.1 {Write tests for ...} - [ ] 3.2 {Write tests for ...} - [ ] 3.3 {Verify integration between ...} ## Phase 4: {Phase Name} (e.g., Cleanup / Documentation) - [ ] 4.1 {Update docs/comments} - [ ] 4.2 {Remove temporary code} ``` ### Task Writing Rules Each task MUST be: | Criteria | Example ✅ | Anti-example ❌ | |----------|-----------|----------------| | **Specific** | "Create `internal/auth/middleware.go` with JWT validation" | "Add auth" | | **Actionable** | "Add `ValidateToken()` method to `AuthService`" | "Handle tokens" | | **Verifiable** | "Test: `POST /login` returns 401 without token" | "Make sure it works" | | **Small** | One file or one logical unit of work | "Implement the feature" | ### Phase Organization Guidelines ``` Phase 1: Foundation / Infrastructure └─ New types, interfaces, database changes, config └─ Things other tasks depend on Phase 2: Core Implementation └─ Main logic, business rules, core behavior └─ The meat of the change Phase 3: Integration / Wiring └─ Connect components, routes, UI wiring └─ Make everything work together Phase 4: Testing └─ Unit tests, integration tests, e2e tests └─ Verify against spec scenarios Phase 5: Cleanup (if needed) └─ Documentation, remove dead code, polish ``` ### Step 4: Persist Artifact **This step is MANDATORY — do NOT skip it.** Follow **Section C** from `skills/_shared/sdd-phase-common.md`. - artifact: `tasks` - topic_key: `sdd/{change-name}/tasks` - type: `architecture` ### Step 5: Return Summary Return to the orchestrator: ```markdown ## Tasks Created **Change**: {change-name} **Location**: `openspec/changes/{change-name}/tasks.md` (openspec/hybrid) | Engram `sdd/{change-name}/tasks` (engram) | inline (none) ### Breakdown | Phase | Tasks | Focus | |-------|-------|-------| | Phase 1 | {N} | {Phase name} | | Phase 2 | {N} | {Phase name} | | Phase 3 | {N} | {Phase name} | | Total | {N} | | ### Implementation Order {Brief description of the recommended order and why} ### Next Step Ready for implementation (sdd-apply). ``` ## Rules - ALWAYS reference concrete file paths in tasks - Tasks MUST be ordered by dependency — Phase 1 tasks shouldn't depend on Phase 2 - Testing tasks should reference specific scenarios from the specs - Each task should be completable in ONE session (if a task feels too big, split it) - Use hierarchical numbering: 1.1, 1.2, 2.1, 2.2, etc. - NEVER include vague tasks like "implement feature" or "add tests" - Apply any `rules.tasks` from `openspec/config.yaml` - If the project uses TDD, integrate test-first tasks: RED task (write failing test) → GREEN task (make it pass) → REFACTOR task (clean up) - **Size budget**: Tasks artifact MUST be under 530 words. Each task: 1-2 lines max. Use checklist format, not paragraphs. - Return envelope per **Section D** from `skills/_shared/sdd-phase-common.md`.