sdd-engineering

Turns an ALREADY-SPECIFIED feature/issue into a concrete Implementation Plan BEFORE any code is written. It does NOT author the specification/requirements — those are an INPUT it verifies, questions where unclear, and improves with recommendations. Module-aware (learns the project's own package/module layout rather than assuming one), folds in relevant per-package lessons-learned if the project keeps them, decomposes work into backend/UI/test tasks, and assigns the exact skills each task must use. Asks the user up front whether to run in MULTI-AGENT mode (non-overlapping parallel file-ownership slices) or a SINGLE-AGENT pass (one ordered sequence). Writes the plan INTO THE PROJECT at <repo-root>/.claude/plans/<slug>.md (the repository's own plans dir — never the global ~/.claude/plans). Use when requirements exist and the codebase is NOT yet modified. Do NOT use to write specs, and do NOT use during implementation. Trigger: "plan the implementation", "implementation plan", "how should we build X".

Implements ONE slice of an Implementation Plan (backend OR UI) and runs in parallel with other implementer instances. Reads .claude/plans/<slug>.md, picks its assigned slice, applies the correct skills per file type (backend skills on backend files, UI skills on frontend files), reads the module's lessons-learned notes before working there (if the project keeps any), writes code, and makes tests pass. Self-reviews ONLY its own diff. Stays strictly within the files its slice owns in the plan — never edits another slice's files. Use when a plan exists with unclaimed tasks. Trigger: "implement this slice", "build the plan", "execute task X".

Requirements-traceability agent. WHEN to use: "verify the plan was implemented", "did we build everything in .claude/plans/<slug>.md", "check traceability against the plan", "has the plan been fully implemented", requirements-traceability of an already-written change against its Implementation Plan (and, when the plan cites one, the upstream spec's EARS AC-N — closing the spec→plan→code loop). Caller MUST name the plan slug. WHEN NOT to use: best-practices or architecture judgement (use the architecture-reviewer agent from the architecture-review plugin), general bug hunting or writing tests (use your project's own tooling for those). Read-only — never edits or rewrites anything.

Authors feature SPECIFICATIONS for Spec-Driven Development (SDD) — the requirements document that comes BEFORE any implementation plan or code. It interviews the user, analyzes the design (the user's description/links, in-repo design docs, existing code, and prior specs/plans) to find gaps, uncovered corner cases, cross-module interactions, and UX improvements, then writes a testable spec whose acceptance criteria are in EARS form. Its ONLY output is a spec file under the repo's top-level `specs/` folder (SPEC-NN, auto-incremented) — it never writes code, plans, or anything outside `specs/`. Can also UPDATE an existing spec (status draft→approved→implemented, Supersedes). Use when a feature needs to be specified. Trigger: "write a spec", "create a specification", "spec this feature", "SDD spec", "EARS acceptance criteria", "specify requirements for X". Do NOT use for implementation planning (use implementation-planner), writing code (use implementer), or open-ended research (delegate to a research agent instead).

Run the Spec-Driven Development EXECUTION workflow against an existing Implementation Plan: implement the plan's slices (multi-agent), architecture-review + fix-iterate until clean, then plan-verify traceability. Does NOT create the spec or the plan — those are run manually upstream via spec-creator and implementation-planner. Optionally takes a spec path, an extra requirements prompt, and design links as added context. Trigger: /run-plan <plan-slug>, "run the plan", "execute the plan", "build by spec".

Capture a retrospective of a just-finished MULTI-AGENT workflow run (e.g. after /run-plan) into a per-run file, so future runs are cheaper and smarter. Reconstructs, from THIS session's context, how the run went — which agents were launched, in what order, tokens/tool-calls/duration each, review→fix rounds — and the qualitative lessons: what was hard vs easy, what context was duplicated across agents, what they missed. Adds a spawn-economy audit, a rework/iteration cost breakdown, and a trend vs previous runs. Writes ONLY under .claude/workflow-runs/; proposes agent/orchestration tuning but never edits agent definitions. Zero new LLM calls. Trigger: /workflow-retro, "retro the run", "workflow retrospective", "how did that run go".