sdd-tasks

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.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "sdd-tasks" with this command: npx skills add gentleman-programming/sdd-agent-team/gentleman-programming-sdd-agent-team-sdd-tasks

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

  • If mode is engram:

    CRITICAL: mem_search returns 300-char PREVIEWS, not full content. You MUST call mem_get_observation(id) for EVERY artifact. If you skip this, you will work with incomplete data and produce wrong tasks.

    STEP A — SEARCH (get IDs only — content is truncated):

    Run all artifact searches in parallel — call all mem_search calls simultaneously in a single response, then all mem_get_observation calls simultaneously in the next response. Do NOT search sequentially.

    1. mem_search(query: "sdd/{change-name}/proposal", project: "{project}") → save ID
    2. mem_search(query: "sdd/{change-name}/spec", project: "{project}") → save ID
    3. mem_search(query: "sdd/{change-name}/design", project: "{project}") → save ID

    STEP B — RETRIEVE FULL CONTENT (mandatory for each):

    Run all retrieval calls in parallel — call all mem_get_observation calls simultaneously in a single response.

    1. mem_get_observation(id: {proposal_id}) → full proposal (REQUIRED)
    2. mem_get_observation(id: {spec_id}) → full spec (REQUIRED)
    3. mem_get_observation(id: {design_id}) → full design (REQUIRED)

    DO NOT use search previews as source material.

    Save your artifact:

    mem_save(
      title: "sdd/{change-name}/tasks",
      topic_key: "sdd/{change-name}/tasks",
      type: "architecture",
      project: "{project}",
      content: "{your full tasks markdown}"
    )
    

    topic_key enables upserts — saving again updates, not duplicates. (Read skills/_shared/sdd-phase-common.md.)

    (See skills/_shared/engram-convention.md for full naming conventions.)

  • If mode is openspec: Read and follow skills/_shared/openspec-convention.md.

  • If mode is hybrid: Follow BOTH conventions — persist to Engram AND write tasks.md to filesystem. Retrieve dependencies from Engram (primary) with filesystem fallback.

  • If mode is none: Return result only. Never create or modify project files.

What to Do

Step 1: Load Skills

The orchestrator provides your skill path in the launch prompt. Load it now. If no path was provided, proceed without additional skills.

Read skills/_shared/sdd-phase-common.md for the engram upsert note and return envelope format.

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.

If mode is engram:

mem_save(
  title: "sdd/{change-name}/tasks",
  topic_key: "sdd/{change-name}/tasks",
  type: "architecture",
  project: "{project}",
  content: "{your full tasks markdown from Step 3}"
)

If mode is openspec or hybrid: the file was already written in Step 3.

If mode is hybrid: also call mem_save as above (write to BOTH backends).

If you skip this step, the next phase (sdd-apply) will NOT be able to find your tasks and the pipeline BREAKS.

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 a structured envelope with: status, executive_summary, detailed_report (optional), artifacts, next_recommended, and risks (read skills/_shared/sdd-phase-common.md for the full envelope spec)

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

sdd-propose

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

sdd-design

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

sdd-spec

No summary provided by upstream source.

Repository SourceNeeds Review