sdd

Use to capture or update domain terms in CONTEXT.md before their meaning drifts — whenever a fuzzy word shows up in an interview, spec, or review and you want one canonical definition plus a NOT-reference so a homonym can't bite you in six months. Triggers on "add term {X}", "what is {X} in our domain", "add to CONTEXT", "fix the glossary", "define {X}", "/sdd:glossary {term}", "додай термін", "онови глосарій", "що означає {X}". Two-level contract: repo-root CONTEXT.md holds project-wide terms, docs/features/{slug}/CONTEXT.md holds feature-scoped ones; readers read both and the per-feature entry wins. Lazy-bootstraps the target from a template, checks BOTH levels for a conflicting existing entry, asks for a one-sentence definition + the concept it's confused with, and appends one line to ## Glossary. Skip generic tech words (HTTP, queue, cache) — those are not domain terms. Output: created/edited CONTEXT.md. Runs anytime, no input gate; specify, clarify, design and api read its ## Glossary as the canonical so

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 AND the feature changes the schema → run `data-model {slug}` first; on a legal no-schema-change skip it derives from the existing schema instead.

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 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).

Use to produce a Software Architecture Document for a feature — Arc42 12 sections + C4 L1/L2 inline + ADRs spawned on a blast-radius gate — once spec.md exists. Triggers on "design {slug}", "architecture for {slug}", "SAD for {slug}", "arc42 for {slug}", "C4 context+container for {slug}", "/sdd:design {slug}", "спроектуй архітектуру {slug}", "SAD для {slug}", "архітектурний документ {slug}". Drafts §1–§12 in-memory, batch-validates each section Socratically (4-state machine), spawns an ADR only when a decision crosses the blast-radius threshold (irreversible / multi-module / has legitimate alternatives), writes each resolved section + its ADRs atomically, then runs a clean-context critic before finalizing. Brownfield: dispatches an Explore subagent to map the repo first. Hard-refuse if spec.md is missing; CONTEXT.md is optional (when present its Glossary is canonical).

Use to fix a reported bug spec-first: reproduce it, trace the symptom to the owning feature's acceptance criteria, pin it with a failing (RED) test, apply the minimal GREEN fix through the same per-task gate implement uses, then patch the spec so the bug class can't silently return. Triggers on "fix {bug}", "fix the bug in {slug}", "bug in {feature}", "/sdd:fix {slug}", "regression in {slug}", "полагодь баг", "виправ багу", "регресія в {slug}", "чому зламалось". Triage is three-way: AC exists and is violated (regression) / AC is ambiguous (spec-bug — patch the wording) / no AC covers it (gap — add one, marked added-by-fix). Works on a repo with no specs at all (soft mode — code-first, recommends survey after). Writes a fix record under docs/features/{slug}/_fixes/ and commits with an SDD-Fix trailer.

Use to implement a feature from its tasks.json with test-driven development — writes a failing test first, makes it pass, refactors, gates, and commits per task. Triggers on "implement {slug}", "build {slug}", "TDD {slug}", "code up the tasks for {slug}", "/sdd:implement {slug}", "імплементуй {slug}", "реалізуй фічу {slug}", "напиши код за задачами". Reads docs/features/{slug}/tasks.json + the upstream artifacts, detects the repo's test/lint/vet commands stack-agnostically, builds a dependency DAG, and runs one of three modes — sequential single-agent TDD, an agent team (TeamCreate), or a dynamic Workflow — chosen from settings + DAG shape with graceful fallback. Hard-refuses if tasks.json is missing.

Use to turn a feature's acceptance criteria into a test plan before any test is written — a table that maps every spec.md §5 acceptance criterion to at least one test, names the test levels (unit / integration / e2e / contract / load) without binding to a language or framework, and fixes the integration and data strategy. Triggers on "plan tests for {slug}", "test plan for {slug}", "how do we test {slug}", "test strategy for {slug}", "/sdd:plan-tests {slug}", "план тестів для {slug}", "як тестувати {slug}", "тест-план". Output: docs/features/{slug}/test-plan.md (separate file for M+), or inline in spec.md for XS/S per the size matrix. Hard-refuse if spec.md is missing → run `specify {slug}` first.

Use to run an independent, clean-context code review of an implemented feature against its spec and acceptance criteria before shipping. Triggers on "review {slug}", "code review the changes for {slug}", "review the diff for {slug}", "is {slug} ready to ship", "/sdd:review {slug}", "переглянь зміни {slug}", "код-рев'ю фічі {slug}", "рев'ю diff". Dispatches the reviewer subagent over the whole feature diff (stage 1 spec/AC compliance, stage 2 quality), collects cited findings, and resolves each with you. Hard-refuses if the feature isn't implemented yet.

Use to keep the portfolio layer above individual features — one living docs/roadmap.md of outcomes, structured Now / Next / Later, that links to per-feature specs without duplicating them. Triggers on "roadmap", "what's next", "prioritize the roadmap", "add to the roadmap", "show the roadmap", "/sdd:roadmap", "роадмеп", "що далі", "пріоритети", "додай у roadmap". Captures a candidate as an outcome/problem (lands in Next/Later, RICE-scored), promotes/demotes between horizons, and renders the board. It is outcome-altitude — NOT a feature list or a dated Gantt; the solution lives in the feature's spec, not here. specify promotes an item to Now; ship moves it to Shipped — so delivery keeps the roadmap in sync.

Use to add Mermaid sequenceDiagram blocks to the SAD's runtime view (sad.md §6) — one per critical flow, showing how a request moves between participants with happy + error paths. Triggers on "sequences for {slug}", "sequence diagram for {slug}", "draw the runtime flow", "add a sequence to the SAD", "/sdd:sequences {slug}", "діаграми послідовності {slug}", "sequence для {slug}", "намалюй потік {slug}". Reads sad.md §5 for participants, drafts each flow from templates/sequence.md with generic participants, walks them Socratically one flow at a time, and writes confirmed blocks into sad.md §6 — they inform data-model indexes downstream. Hard-refuse if sad.md is missing → run `design {slug}` first.

Use to close the loop after review — verify the feature actually works, write the changelog / knowledge-base note, and open the pull request. Triggers on "ship {slug}", "open a PR for {slug}", "changelog for {slug}", "prepare {slug} for merge", "/sdd:ship {slug}", "відправ фічу {slug}", "створи PR для {slug}", "changelog для {slug}". Re-runs the gate, runs the app/feature to confirm the spec's outcomes for real (not just green tests), drafts a changelog + PR body that link spec/ AC/ADRs, and proposes the PR command for whatever forge the repo uses. Never auto-merges to main.

Use to turn a raw feature idea into a reviewed spec.md — a lightweight Socratic interview front (capture the idea, deep-dive the problem) merged with a full product spec (context, goals, user stories, acceptance criteria, NFRs, KPIs). Triggers on "specify {slug}", "spec for {slug}", "write the spec", "capture this idea", "draft requirements for {slug}", "/sdd:specify {slug}", "напиши специфікацію {slug}", "опиши вимоги", "зафіксуй ідею". Opens by setting the interview-depth dial (easy/medium/hard), drafts from templates/spec.md, validates each acceptance criterion Socratically, runs a clean-context critic, then writes docs/features/{slug}/spec.md. The ideation analyses (competitive research, strategic approaches, multi-perspective review, devil's-advocate) run as named subagents gated by the depth dial — easy skips them, hard runs the full suite.

Use to establish the repo's architecture map the rest of the pipeline reads. Two modes: on an EXISTING codebase it scans once and persists what's there; on an EMPTY/greenfield repo it runs a short, level-adaptive foundation session — picks the stack / folder structure / data approach / conventions WITH you (defaults-heavy), fixes them as the foundation + foundational ADRs, and emits a scaffold tasks.json that implement materializes into a real skeleton. Triggers on "survey the codebase", "map the architecture", "set up a new project", "bootstrap the foundation", "/sdd:survey", "вивчи кодову базу", "карта архітектури", "новий проєкт", "заклади фундамент". Output: docs/architecture-map.md (+ adr/ + scaffold tasks.json on greenfield). Records reflects_commit for staleness; reads, never overwrites, an authored architecture doc.

Use to break a designed feature into atomic, ≤1-day tasks with a dependency graph, a per-task Definition of Done, and a machine-readable tasks.json that the implement engine consumes. Triggers on "task breakdown for {slug}", "break down tasks for {slug}", "tasks for {slug}", "plan the work for {slug}", "/sdd:tasks {slug}", "розбий на задачі {slug}", "декомпозиція {slug}", "список задач". Reads spec.md + sad.md + Accepted ADRs (+ data-model + openapi if present), writes docs/features/{slug}/tasks/{_epic,tracker,<task>}.md AND docs/features/{slug}/tasks.json. Tracker export to any issue tracker is optional and tool-neutral. Hard-refuses if spec.md or sad.md or an Accepted ADR is missing.

Use to open the SDD visual dashboard — the local read-only browser UI that shows every feature's pipeline stage, renders its artifacts (markdown, mermaid C4/sequence/ER, OpenAPI as plain YAML), and drives the pipeline by sending /sdd:<skill> commands back into this live session. Triggers on "start the dashboard", "open the SDD dashboard", "sdd dashboard", "/sdd:start", "show the pipeline UI", "відкрий дашборд", "запусти панель SDD". The sdd-dashboard MCP server auto-starts at session open (via .mcp.json), resolves the project from CLAUDE_PROJECT_DIR, binds its loopback HTTP listener, and writes the dashboard URL (with a per-session capability token) to ~/.claude/sdd-dashboard/current.url — so start's job is simply to READ that file and print the URL. No MCP tool call, no channel round-trip on the common path. Opt-in: requires dashboard_enabled: true in .claude/sdd.local.md and Bun installed; if either is missing it prints guidance and exits cleanly (pure-markdown skills are unaffected).

Use to classify a feature into XS/S/M/L/XL and write docs/features/{slug}/.size plus the pipeline route docs/features/{slug}/.route (quick|standard|full) so later skills know how much of each artifact to produce and how handoffs resolve skips. Triggers on "classify size", "feature size", "is this XS or M for {slug}", "size {slug}", "change route", "/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, derives the default route (XS/S→quick, M→standard, L/XL→full), confirms size + route in ONE question, and writes the one-line .size and .route files — 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 BEFORE specify to stress-test a raw idea — pressure-test it before you commit to a spec. A Socratic interview that surfaces hidden assumptions, names tradeoffs, exposes imprecisions, and proposes fresh angles. Scope is any idea (product, content, business, architecture, refactor approach), but in an SDD repo the natural exit is /sdd:specify on the surviving idea. Triggers on "interview {slug}", "stress test {slug}", "challenge this", "poke holes", "rip this apart", "/sdd:interview {slug}", "погрилити", "розбери цю ідею", "розʼєби". Runs 3 phases (understand intent → surface tradeoffs and weak spots → propose new angles) via AskUserQuestion, ends with a summary of risks, alternatives, and the next step. Optional — the backbone starts at specify; reach for interview when the idea itself isn't settled yet.