mcpField
S
sdd-tasks

sdd-tasks

github.com/gentleman-programmingDevelopment1.2k119 installsUpdated 31w ago
Repository

About sdd-tasks

sdd-tasks is a software-development skill that turns a proposal, specifications, and design into a phased, actionable task breakdown. It supports Engram and OpenSpec artifact workflows, with persistence determined by the selected mode.

Key features

  1. 01Analyze files, dependencies, and tests
  2. 02Create ordered implementation phases
  3. 03Write specific, verifiable checklist tasks
  4. 04Persist artifacts by selected mode

Use cases

  1. 01Break a design into implementation steps
  2. 02Plan test-first work for a change
  3. 03Store task plans in Engram or OpenSpec

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/gentleman-programming/agent-teams-lite --skill sdd-tasks

After installing, type/sdd-tasksin Claude Code to confirm it loaded.

Details

From the project README

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:

CriteriaExample ✅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"
SmallOne 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 (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.

Comments

Markdown supported