Sdd Tasks
Turn an approved SDD design into an atomic, ordered tasks.md plan your agent can execute via sdd-apply.
Overview
Sdd Tasks is an agent skill most often used in Validate (also Build PM) that breaks an SDD design into atomic, path-specific, verifiable tasks in tasks.md before implementation.
Install
npx skills add https://github.com/fearovex/claude-config --skill sdd-tasksWhat is this skill?
- Produces tasks.md: atomic, ordered, verifiable work list—mandatory input before sdd-apply
- Triggers via /sdd-tasks <change-name>, task plan, and task breakdown phrasing
- Reads prior design artifact and SDD shared phase context (project load + spec preload)
- Skill resolution order: project-local .claude/skills then global ~/.claude/skills fallback
- Version 3.0 procedural skill aligned with fearovex SDD orchestration
- Skill metadata version 3.0
- Each task must be atomic, concrete with file path, and verifiable
- Implementation blocked without an approved tasks file per skill purpose
Adoption & trust: 1 installs on skills.sh; 1 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You have a design spec but no ordered, checkable task list your implementation agent can follow without reopening architecture debates.
Who is it for?
Builders already using SDD artifacts (design → tasks → apply) who want deterministic agent implementation steps.
Skip if: Ad-hoc coding without a prior design file, or teams that do not use the sdd-apply gate.
When should I use this skill?
/sdd-tasks <change-name>, task plan, break down implementation, task breakdown, or sdd tasks.
What do I get? / Deliverables
You get an approved tasks.md ready for sdd-apply, with each task atomic, concrete, and markable done.
- tasks.md atomic ordered task plan
- Verifiable checklist consumable by sdd-apply
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf in Validate scope because task breakdown locks implementation boundaries after design and before coding—the gating artifact for spec-driven delivery. Scope subphase reflects splitting the file matrix into verifiable units with paths, not shipping features or running tests yet.
Where it fits
After mem_search loads sdd/{change} design, generate tasks.md so scope is executable before prototype code.
Split a multi-file feature design into ordered tasks with paths for the apply sub-agent.
Break a launch checklist design into atomic release tasks without skipping verification steps.
How it compares
Structured SDD task decomposition skill, not a generic brainstorming or one-shot code generator.
Common Questions / FAQ
Who is sdd-tasks for?
Solo developers and small teams running fearovex-style SDD with Claude who need a formal tasks.md between design approval and coding.
When should I use sdd-tasks?
Right after the design artifact exists and before sdd-apply—typically Validate scoping or early Build PM when locking implementation order.
Is sdd-tasks safe to install?
It reads project specs and writes planning files; review the Security Audits panel on this page and keep sensitive specs out of shared skill paths if needed.
Workflow Chain
Then invoke: sdd apply
SKILL.md
READMESKILL.md - Sdd Tasks
# sdd-tasks > Breaks down the design into an atomic, ordered, and verifiable task plan. **Triggers**: `/sdd-tasks <change-name>`, task plan, break down implementation, task breakdown, sdd tasks --- ## Purpose The task plan converts the design into an **executable work list**. Each task is atomic (one single thing), concrete (has a file path), and verifiable (can be marked as done). It is the input for `sdd-apply`. Without an approved tasks file, nothing gets implemented. --- ## Process ### Skill Resolution When the orchestrator launches this sub-agent, it resolves the skill path using: ``` 1. .claude/skills/sdd-tasks/SKILL.md (project-local — highest priority) 2. ~/.claude/skills/sdd-tasks/SKILL.md (global catalog — fallback) ``` Project-local skills override the global catalog. See `docs/SKILL-RESOLUTION.md` for the full algorithm. --- ### Step 0 — Load project context + Spec context preload Follow `skills/_shared/sdd-phase-common.md` **Section F** (Project Context Load) and **Section G** (Spec Context Preload). Both are non-blocking. --- ### Step 1 — Read prior artifacts I must read: - The design artifact (the file matrix and approach): - `mem_search(query: "sdd/{change-name}/design")` → `mem_get_observation(id)`. - If not found and Engram not reachable: design content passed inline from orchestrator. - The spec artifact (the success criteria): - `mem_search(query: "sdd/{change-name}/spec")` → `mem_get_observation(id)`. - If not found and Engram not reachable: spec content passed inline from orchestrator. - The proposal artifact — specifically the `## Supersedes` section: - `mem_search(query: "sdd/{change-name}/proposal")` → `mem_get_observation(id)`. - If not found and Engram not reachable: proposal content passed inline from orchestrator. ### Step 2 — Analyze dependencies between tasks I identify the natural implementation order: - Types/interfaces before their usage - Providers/services before their consumers - Schema/migration before the code that uses them - Unit tests alongside the code (not at the end) - **Removals and replacements BEFORE additions** (see Step 3 below) ### Step 3 — Generate removal tasks from Supersedes section #### Step 3a — Check Supersedes 1. Read `## Supersedes` from proposal.md. 2. **If section is absent** (older archived change): log `INFO: no Supersedes section in proposal.md — skipping removal task generation` and proceed to Step 4 with standard phase organization. 3. **If section states "None — purely additive change"**: skip removal task generation; proceed to Step 4. 4. **If section has REMOVED or REPLACED items**: proceed to Step 3b. #### Step 3b — Generate removal/replacement tasks For each **REMOVED** item in Supersedes: - Generate one task titled `Remove: [feature name]` with: - File paths to delete or modify - Acceptance criterion: "File deleted AND no runtime errors in related flows" - Spec reference: linked spec requirement name (if spec exists for this removal) For each **REPLACED** item in Supersedes: - Generate two tasks in dependency order: 1. `Remove old: [old feature name]` — delete/unregister the old implementation 2. `Implement new: [new feature name]` — add the replacement (link to spec requirement) - Note explicit dependency: task 2 cannot start until task 1 is complete. #### Step 3c — Phase 1 organization All removal and replacement tasks (from Step 3b) MUST be grouped into **Phase 1: Removals and Replacements**. Standard addition/implementation tasks start from Phase 2 or later. Phase 2 MUST NOT begin until Phase 1 is complete — enforce this with an explicit sequencing note in tasks.md. **Removal task format:** ```markdown ### Phase