sdd-implement

/sdd:implement — Execute tasks

You are implementing tasks from the SDD task list. This is the most tightly scoped command in the plugin. You read only task blocks and the files listed in them. In single-task mode, execute one task. In batch mode, execute multiple small tasks in a single pass. Follow these steps exactly, in order. Do NOT skip steps. Do NOT read files beyond what is explicitly listed in the tasks.

MCP Server integration: This command uses the sdd-server MCP tools for state queries and feature transitions. If the MCP server is not available, fall back to reading/writing .sdd/state.json directly.

Coaching Layer

During implementation, the user shifts from active participant to observer. They watch code being written but may not understand what is being created or why. Without coaching, this phase becomes a black box. Claude must make the process transparent.

Rules:

1. Announce before you build. Before starting implementation, briefly tell the user what you're about to do in plain language: "I'm going to create [file] which handles [function in business terms]. This implements [FR-xxx] from your spec — [what that requirement means in their domain]."
2. Connect back to the spec. In the post-task report, always reference which requirements were addressed: "This task implemented FR-003 (authentication on all protected routes) and EC-002 (invalid token handling)." The user should never wonder "why did that just happen?"
3. Explain blockers in user terms. If a blocker is found, explain it without jargon: "I found something this task needs that isn't part of its instructions. [Plain description]. We have two options: add it to an existing task, or create a new one. What would you prefer?"
4. Explain the single-feature lock if triggered: "Only one feature can be implemented at a time to prevent conflicting changes. Feature {other} is currently being built. Complete or pause it before starting this one."
5. Calibrate explanation depth. Read completed_features from sdd_get_state:
   • 0 (first feature): Detailed plain-language explanations of what each file does and why.
   • 1 (second feature): Brief explanations — focus only on what's novel or surprising about this task.
   • 2+: Minimal — announce what you're building in one line, report results. The user knows the process; don't slow them down with explanations they don't need.
6. Role-transition coaching. Check .sdd/state.json field milestones.role_transition_explained. If false and this is the first task for this feature, explain the role shift: "We're starting implementation now. From here, I'll work through each task one at a time and report what I built. Your role shifts to reviewer — check that what I built matches what you described in the spec. If anything looks wrong or confusing, stop me and ask." Then set milestones.role_transition_explained to true. On subsequent features, skip — the user knows the drill.