sdd

Clean-context multi-perspective reviewer of an SDD feature's candidate approaches. Use during specify's ideation pass (hard depth) to pressure-test the three strategic approaches from three lenses — Engineer, Executive, UX — so the recommendation isn't blind to cost, feasibility, or the user. Read-only; returns one 3×3 synthesis matrix (lens × approach) scored +/0/− with ≤6-word justifications. The Engineer lens stays abstract (latency/complexity/integration surface), never product or library names.

Clean-context coherence critic for SDD artifacts (a spec or a SAD). Use after a Socratic pass to detect cross-section drift, coherence damage from user edits, structural gaps, and constraint/ quality leaks the per-section walk could not see. Read-only; reads the upstream artifacts itself; emits cited findings only. It judges coherence, it does not propose new design.

Clean-context adversary for SDD. Two modes, named by the dispatch prompt. (A) Ambiguity hunt over a written spec — used by clarify to find where two competent engineers would reasonably build different things (vague terms, unmeasured NFRs, under-specified ACs, conflicts). (B) Failure-mode hunt over a raw idea + candidate approaches — used by specify's ideation pass (medium/hard) to find how it fails in production (attack vectors with monitoring/churn/incident signals). Read-only; reads its inputs itself; emits cited findings. It surfaces problems, it does not resolve them.

Read-only brownfield scout for SDD. Use when a skill (design, data-model) needs the existing codebase mapped before it designs against it — module boundaries, the patterns already in use, where similar features live, the migration/test conventions — or when fix needs a reported symptom localized to its code path. Returns a concise structured map (or file:line root-cause candidates); it locates and summarizes, it does not edit, review, or design.

Makes a failing SDD test pass — the GREEN + REFACTOR + GATE steps of test-driven development. Use after test-author has produced a red test for a task. Given the task and its quoted failing line, it writes the minimal production code to pass, refactors while staying green, and runs the per-task gate (unit + integration-if-available + lint + vet). It never weakens or edits the test to force a pass.

Use to derive the API contract for a feature — an OpenAPI 3.1 document at docs/features/{slug}/contracts/openapi.yaml plus a drift/sync report (and an events doc when the feature has async flows). Triggers on "api for {slug}", "openapi for {slug}", "API contract for {slug}", "lock the interface for {slug}", "events for {slug}", "/sdd:api {slug}", "контракт API для {slug}", "OpenAPI для {slug}", "опиши ендпоінти". The contract is never hand-written: it is a derived function of data-model.md (typed fields + constraints), the sad.md §6 sequence diagrams (error branches, async actors), and spec.md acceptance criteria. Runs an inline drift check (does the contract match the model and the sequences?) and a reconcile mode. Hard-refuse if data-model.md is missing → run `data-model {slug}` first.

Use to run an ambiguity sweep over a written spec.md and close every under-specified point before planning or design proceeds — so two engineers can't reasonably build different things from the same spec. Triggers on "clarify {slug}", "find ambiguities in {slug}", "is the spec ready", "sharpen the spec", "/sdd:clarify {slug}", "прояснити специфікацію", "знайди неоднозначності {slug}", "чи готова специфікація". Re-reads the spec, dispatches a clean-context devil's-advocate subagent to list where the spec forks, then for each ambiguity runs AskUserQuestion to RESOLVE it (tighten §1/§5/§6 in place) or DEFER it (→ §8 Open questions with owner+due). Output: an updated docs/features/{slug}/spec.md with every ambiguity resolved or deferred — none dangling. Hard-refuse if spec.md is missing.

Use to classify a feature into XS/S/M/L/XL and write docs/features/{slug}/.size so later skills know how much of each artifact to produce. Triggers on "classify size", "feature size", "is this XS or M for {slug}", "size {slug}", "/sdd:classify-size {slug}", "класифікуй розмір {slug}", "який розмір фічі", "XS чи M". Asks four AskUserQuestion (PR count / time / new module-API-migration / breaking changes), maps to a size class via the shared size matrix, confirms with the user, and writes the one-line .size file — the source of truth; the feature_size: frontmatter mirrors in spec.md and sad.md are re-synced to it on every (re)classification.

Use to design the data model AND generate the actual forward + rollback migrations in one pass — shippable SQL, not a plan. Triggers on "data model for {slug}", "schema for {slug}", "generate migrations for {slug}", "DB design + migration", "/sdd:data-model {slug}", "модель даних для {slug}", "схема для {slug}", "згенеруй міграції". Reads spec.md §5 + sad.md §5 building blocks + the §6 sequence diagrams, then writes docs/features/{slug}/data-model.md plus paired *.up.sql / *.down.sql migrations STAGED under docs/features/{slug}/migrations/ (NOT the live migrations/ tree — implement promotes them when the feature is actually built) and an audit report. Greenfield-first; brownfield delta via --mode brownfield; drift-only via --drift-only. Hard-refuses if spec.md or sad.md is missing. Stack-agnostic: detects and FOLLOWS the repo's DB + migration conventions and domain layer — it imposes no DB philosophy and writes no rules file.

Use to record a post-hoc or asynchronous architecture decision as a MADR ADR when it was NOT captured during the synchronous design pass — a choice made in code, in a chat, on a whiteboard, or one a tasks/review gate flagged as missing. Triggers on "ADR for {decision}", "adr for {slug}", "document the decision on {topic}", "lock in the decision about {X}", "MADR for {topic}", "/sdd:decide-adr {slug} {title}", "створи ADR для рішення", "задокументуй рішення", "ADR на {тему}". Confirms the decision is ADR-worthy via the blast-radius gate, picks the next 4-digit number, copies design's MADR template, and fills context / drivers / considered options / outcome / honest consequences. Supports a Proposed → Accepted review flow. Output: docs/features/{slug}/adr/NNNN-{title}.md. For decisions made live with the user, use `design` — it spawns ADRs inline (Accepted).