sdd-plugin

This skill should be used when the user asks to "close out the plan", "archive the plan", "mark the requirement shipped", or "this feature is done — close it out". The SDD close-out — confirms the document-side Definition of Done (spec status, index, traceability), flips the plan to done and `git mv`s it to `plans/archive/` inside the implementing PR, and updates AGENTS.md tables if user-facing. Not for merging / PR / branch cleanup (superpowers finishing-a-development-branch); not for running tests (superpowers verification-before-completion) or the drift check (sdd-trace).

This skill should be used when the user asks to "run the SDD review", "review this PR/change for spec conformance", "dispatch the reviewers and post findings to the PR", or "spec-aware code review before merge". Opt-in orchestration — dispatches the installed generic code reviewers plus the SDD traceability auditor and spec-conformance reviewer, consolidates the findings, and (optionally) posts them to the PR. It sequences and adds the SDD lens; it does not replace generic review. Not for authoring (sdd-specify), the in-session drift-only scan (sdd-trace), or whether the tests pass (superpowers verification-before-completion).

This skill should be used when the user mentions spec-driven development concepts outside a specific artefact action — "what is SDD", "explain spec-driven development", "how does this repo's spec workflow work", "where does the spec fit with planning/building", or vocabulary like normative, RFC-2119, traceability, drift, ADR, requirement-vs-spec. Provides SDD awareness, explains the methodology, routes intent to the right skill, and maps how SDD complements the superpowers engineering loop. Not for performing an artefact action — use the specific sdd-* skill.

This skill should be used when the user asks to "set up SDD", "initialize spec-driven development", "scaffold the docs tree", "add SDD structure to this repo", or "create the requirements/specifications layout". Creates the SDD docs/ tree, document templates, the .sdd.yaml descriptor, AGENTS.md, and the process docs — idempotently. Not for authoring a requirement, spec, or decision in an already-scaffolded repo (use sdd-specify).

This skill should be used when the user asks to "add a requirement / capability", "write or extend a spec", "make this behaviour normative (RFC-2119)", "record an ADR / architectural decision", or "resolve a STRAND". The SDD definition layer — authors the `REQ`, the canonical RFC-2119 `SPEC §`, and the `ADR`, assigning identifiers and wiring traceability. Not for exploring/design (superpowers brainstorming first); not for planning or building (superpowers writing-plans / executing-plans); a traceability audit (sdd-trace); or a one-line edit to an existing spec § (open the file directly).

This skill should be used when the user asks to "show traceability for REQ-X", "assemble context for REQ-X", "what implements/tests this requirement", "are there orphan requirements", or wants a quick in-session drift / spec-check scan. Read-only — assembles the one-shot context bundle for a REQ and reports drift/orphans in-session (the spec-check analogue). Not for generic tests/build verification (superpowers verification-before-completion); not for authoring (sdd-specify), close-out (sdd-archive), or a heavy whole-repo / pre-release audit (sdd-traceability-auditor agent).