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.
54
60%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./skills/sdd-tasks/SKILL.mdYou 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.
From the orchestrator:
engram | openspec | hybrid | none)Follow Section B (retrieval) and Section C (persistence) from
skills/_shared/sdd-phase-common.md.
sdd/{change-name}/proposal (required), sdd/{change-name}/spec (required), sdd/{change-name}/design (required). Save as sdd/{change-name}/tasks.skills/_shared/openspec-convention.md.tasks.md to filesystem. Retrieve dependencies from Engram (primary) with filesystem fallback.Follow Section A from skills/_shared/sdd-phase-common.md.
From the design document, identify:
IF mode is openspec or hybrid: Create the task file:
openspec/changes/{change-name}/
├── proposal.md
├── specs/
├── design.md
└── tasks.md ← You create thisIF 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.
# 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}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 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, polishThis step is MANDATORY — do NOT skip it.
Follow Section C from skills/_shared/sdd-phase-common.md.
taskssdd/{change-name}/tasksarchitectureReturn to the orchestrator:
## 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.tasks from openspec/config.yamlskills/_shared/sdd-phase-common.md.6901875
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.