sdd-tasks

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

# 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:

## 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. Route each task to the correct Sando specialist per the
`[sando-tokens]` / `[sando-developer]` / `[sando-quality]` / `[sando-storybook]` tags.
NEVER delegate to `sdd-apply` in this project.

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.