sdd-engineering

Execute an existing PLAN.md — sdd-engineering:implementer(s) → sdd-engineering:plan-verifier → architecture-review:architecture-reviewer, looping fixes back to sdd-engineering:implementer with a capped iteration budget.

Implementation planner for the Spec-Driven Development workflow. Use when a feature, fix, or refactor needs a structured implementation plan before code is written. Turns a SPEC-NN.md (or, if none exists, a direct request) into a PLAN.md — the HOW, never the WHAT. Reads the spec as ground truth for goals/acceptance-criteria/contracts, reviews it for implementation feasibility and architecture fit, surfaces its own recommendations, and asks whether to run single-agent (one implementer, sequential) or multi-agent (parallel implementers per phase) mode before finalizing. Does not write specs — that is sdd-engineering:spec-creator's job. Applies typescript-expert/zod/security always, and reads the relevant domain-skill file on demand for whichever surface the task touches (onion-architecture, fastify-best-practices, drizzle-orm-patterns, postgresql-table-design, ui-architecture, next-best-practices, react-best-practices, etc.). Use proactively before any non-trivial implementation.

Code implementer for the Spec-Driven Development workflow. Use when a PLAN.md exists and one phase needs to be executed. Writes code and makes tests pass — nothing else. Applies the relevant engineering-paved-path skills to whichever surface a task touches (backend, frontend, data), and reads the repository's own INSIGHTS.md / architecture docs before writing code. Runs in parallel — spawn one implementer per independent plan phase.

Plan verifier for the Spec-Driven Development workflow. Use after an implementation phase is complete, to verify that every task in PLAN.md was actually delivered. Checks task by task that acceptance criteria are met, tests exist, and nothing was skipped. Designed adversarially — its job is to find gaps, not confirm success. Produces a VERIFICATION.md report. Does NOT review code style or best practices.

Specification writer for Spec-Driven Development. Use when a feature, fix, or refactor needs a formal SPEC-NN.md written before planning begins — translating a fuzzy request into EARS-formatted acceptance criteria, explicit goals/non-goals, architecture/workflow diagrams, service contracts, tagged input provenance, and untrusted-input handling — all without implementation detail (no file paths, function names, or code). Produces exactly one Markdown spec per feature, scoped to a single component's specs folder. Actively hunts for missing edge cases, cross-component communication assumptions, and UX gaps. Never resolves a genuine ambiguity itself — surfaces it as [NEEDS CLARIFICATION] instead of guessing. Can delegate focused research questions to research-tools:researcher (parallel instances for independent sub-questions) and genuine behavioral/UX ambiguities to research-tools:brainstorm — never implementation-option questions, which stay downstream with sdd-engineering:implementation-planner. Produces a Traceability table (AC-N → evidence) and a Verification section (per-AC check recipe) as part of the spec. Never finalizes a spec while a mandatory requirement lacks a covering acceptance criterion — the gap is either given an AC-N or surfaced under [NEEDS CLARIFICATION]. Use proactively before brainstorm/implementation-planner on any feature where requirements aren't already unambiguous and testable.

Captures session learnings into repository-local INSIGHTS.md files to build compounding project knowledge. Triggered at the end of any coding session lasting 30+ minutes, or whenever the user runs /engineering-insights. Discovers where INSIGHTS.md files live in the current repo (does not assume a fixed layout), extracts patterns, mistakes, decisions, and project-specific context from the session, and appends datestamped entries. Do not trigger for trivial single-file edits with no discoveries.

Runs an already-approved DevDigest Implementation Plan end-to-end: dispatches sdd-engineering:implementer agents per the plan's DAG (multi-agent by non-overlapping owned paths, or single-agent), then gates with architecture-review:architecture-reviewer + sdd-engineering:plan-verifier in parallel, then resolves their comments in a bounded fix loop. Starts FROM a plan — spec authoring (sdd-engineering:spec-creator) and planning (sdd-engineering:implementation-planner) are run separately/manually beforehand. Never pushes or merges. TRIGGER when: "/run-plan", "run-plan plan:<path>", "run the plan", "run the DevDigest plan", "execute the approved plan". Prefer this over the generic `implement` skill for DevDigest's DAG/owned-path multi-agent execution. Does NOT cover: writing specs, writing the plan, authoring tests (test-writer is not invoked here), pushing/merging (run pr-self-review before push).

Guides the developer through the per-branch retro process at merge or feature completion: collect git-diff statistics, run tests only for touched packages (record "—" for untouched ones), and append one ledger table row plus one prose section to docs/retros/ledger.md. Triggered when a branch/feature is ready for retro (at merge time, or at retro time for long-lived branches), or whenever the user runs /workflow-retro. Append-only — never rewrites existing ledger entries.