SDD Engineering

Turns ALREADY-DEFINED requirements (a spec, ticket, or feature request) into a structured, project-aware **Implementation Plan** — the HOW, never the WHAT. Read-only: it verifies the incoming requirements, asks 1–3 clarifying questions when they are ambiguous, recommends how to build it better, and confirms with the user whether to execute in MULTI-AGENT mode (parallel `implementer` agents, one per task unit, tagged backend|ui) or a SINGLE-AGENT pass — then emits a file-level plan whose task units are tagged backend|ui, each with the exact skills to apply, a definition-of-done, and (multi-agent only) a parallelization graph. It does NOT author, expand, or finalize the specification. Use when you HAVE requirements and need a plan BEFORE writing code — not the code itself, and not the spec.

Executes ONE task unit from an Implementation Plan — backend OR frontend — worktree-isolated. Designed to run MANY-in-parallel: each instance works in its own git worktree, touches only the files its task unit names, applies its preloaded skill set for the unit's track, makes the relevant tests pass, and self-reviews ONLY the code it wrote. Use for a planned, file-scoped task tagged `track: backend` or `track: ui`; NOT for open-ended planning (that is implementation-planner).

READ-ONLY verification that an implementation matches its PLAN / REQUIREMENTS. Given an Implementation Plan (summary, acceptance criteria, task units + definition-of-done) and the already-written code, it checks whether EVERY requirement was actually implemented — a requirements-coverage / traceability pass, NOT a code-quality or best-practice review. Every verdict is grounded in a real `file:line`; absent evidence is reported as NOT FOUND, never assumed. Writes NOTHING. Use to confirm done-ness against a plan; for architecture quality use architecture-reviewer, for line-level correctness use /code-review.

Autonomous SDD spec author. Given a feature request / design-doc / code area / UI mockup (plus optional pre-gathered research), it GROUNDS on the codebase, ANALYZES the design against the requirements-engineering rubric, DRAFTS a spec (from the project's spec template if it has one) leaving every unresolved decision as a [NEEDS CLARIFICATION: NC-n] marker (never asks the user — it cannot), writes SPEC-NN-YYYY-MM-DD-<slug>.md under the project's spec directory (default specs/), registers it in the spec index, and returns the machine-readable list of open NC-n. In RESOLVE mode it takes an existing spec path + answers and folds them in, removing resolved markers and raising Status. Writes ONLY under the spec directory. Runs standalone (headless drafts) or driven by the write-spec loop. NOT for the HOW (that is implementation-planner) and NOT for code or docs.

Orchestrates the PLAN phase of Spec-Driven Development — the thin main-thread wrapper around the read-only implementation-planner agent, mirroring how sdd-engineering:write-spec wraps spec-creator. Takes an APPROVED spec and plans its IMPLEMENTATION: invokes implementation-planner to produce the file-level HOW, relays the planner's clarifications via AskUserQuestion, fans out researcher agents for any [RESEARCH NEEDED] gap, confirms multi- vs single-agent execution, and — the thing the read-only planner cannot do — PERSISTS the plan to the plan directory (default plans/, files PLAN-*.md). Runs BETWEEN sdd-engineering:write-spec (WHAT) and sdd-engineering:run-plan (build). Orchestrates only; writes no code and authors no spec.

The craft of turning fuzzy intent into testable requirements — the shared rubric behind a good spec. Covers EARS acceptance criteria (the vague→testable translation), INVEST user stories, acceptance-criteria smells, a completeness checklist for what's missing (failure modes, boundaries, concurrency, tenancy, untrusted input, cross-module, non-functional), and explicit-boundary discipline (Non-goals, MoSCoW, anti-gold-plating). Use WHENEVER authoring or reviewing requirements / acceptance criteria — invoked by the sdd-engineering:write-spec skill, and reusable by implementation-planner and plan-verifier for a shared definition of 'a good criterion'.

Post-run retrospective for a MULTI-AGENT workflow (the SDD sdd-engineering:run-plan pipeline, or any fan-out of subagents). Aggregates a DURABLE per-step telemetry ledger (default retros/ledger.jsonl under the project root, appended by a SubagentStop/Stop hook) to reconstruct the run's telemetry (agents launched, launch order, per-agent tokens / tool-uses / duration, failures & retries, parallelism), synthesizes qualitative insights (which agents were hard vs easy, what context was duplicated across agents, what information was missed or re-worked), emits a retro report under retros/, appends a cross-run trend row, and routes durable orchestration learnings to project memory. It evaluates the ORCHESTRATION — not the code (that is engineering-paved-path:engineering-insights), not the requirements (that is the spec).

Executes an already-approved SDD plan through build → review → fix → gate. Takes a persisted PLAN-*.md (the HOW — produced SEPARATELY via sdd-engineering:plan-implementation) and optionally its spec, fans out implementer per task unit (parallel, worktree-isolated), runs the review gates (plan-verifier + architecture-reviewer + /code-review) in parallel, drives a BOUNDED post-review fix loop, and stops at the pre-push gate. It ORCHESTRATES only — writes no code itself; the main thread owns user Q&A, parallel fan-out, /code-review, and worktree integration. Spec authoring (sdd-engineering:write-spec) and planning (sdd-engineering:plan-implementation) are run manually before this.

Orchestrates SDD spec authoring. Takes a feature request / design-doc / code area / UI mockup, invokes the autonomous spec-creator agent to ground + analyze + draft the spec (WHAT, not HOW), then runs the clarification loop: reads back the agent's [NEEDS CLARIFICATION] markers, asks the user LIVE via AskUserQuestion, and re-invokes the agent to fold answers in — until no blocking question remains. Use WHENEVER a spec / requirements must be written interactively before planning or coding.

2 hooks across 2 events