sdd-workflow

SDD step 2 — turn an agreed spec or set of requirements into a phased implementation plan (HOW).

SDD step 3 — execute an implementation plan by dispatching implementer agents, respecting its dependency DAG.

SDD step 5 — retrospective on the multi-agent run that just finished: cost, friction, waste, and what to change.

SDD step 1 — write a spec (WHAT/WHY) for a feature before any plan or code exists.

SDD step 4 — check that every plan item / acceptance criterion is actually implemented, with evidence.

Use proactively when an agreed set of requirements (a spec, ticket, or clear request) needs a structured Implementation Plan before any code is written. Read-only architect that verifies the incoming requirements, flags gaps, recommends a better approach where it sees one, and maps the work onto the project's actual modules as a phased, file-specific plan with per-task skill assignments, owned paths, a dependency DAG, and measurable acceptance criteria. Does NOT author or edit specifications — it plans against requirements it is given. Writes only the plan file; never touches product code.

Read-only requirements-completion checker. Use after a feature is claimed done to verify every plan item / acceptance criterion is actually implemented — focus on completeness and traceability, not code quality.

Use proactively when a feature or change needs a written specification before any plan or code exists. Read-only-except-specs author for Spec-Driven Development — turns a request plus design sources (text, Figma links, screenshots, generated design skeletons, existing docs/plans, repo code) into a single concise spec file with EARS acceptance criteria, edge cases, cross-module interactions, and contracts. When a design is provided it is treated as the source of truth: the spec mirrors it exactly — layout, spacing, typography, colour, variants, states, copy — reuses any generated skeleton's styles one-to-one, and specifies only what the design shows plus the cases it leaves uncovered. Re-verifies the finished spec against the original design, and asks the author about anything it cannot resolve. Writes ONLY spec files under a `specs/` directory; never product code, never the "how".

Post-mortem / retrospective for a multi-agent run. Run it AFTER a workflow finishes (/run-plan, the spec → plan → implement chain, a Workflow() fan-out, or any batch of sub-agents) to collect how the run actually went and turn it into actionable change. Gathers cost & resource metrics (tokens, cache efficiency, tool calls, durations, agent count, launch order, parallelism), reconstructs qualitative insights (what was hard, what was easy, what context was duplicated, what was missed), and ends with concrete recommendations (improve an agent's brief, pre-fetch a shared file once, merge or split agents, change concurrency). Outputs a full report to chat and appends one trend row to docs/retros/ledger.md. TRIGGER only when explicitly asked: "/workflow-retro", "retro this run", "workflow retrospective", "analyze that multi-agent run", "how did that workflow go". Does NOT cover: running the workflow itself, editing product code, pushing/merging.