Specify

Skill: specify

Turns a one-line idea into a reviewed spec.md: a lightweight interview captures and stress-tests the idea, then the skill drafts a product spec (context → goals → user stories → acceptance criteria → NFRs → KPIs), validates it Socratically, and runs a clean-context critic before writing. Less typing, more reviewing. This file is the spine; detail lives in references/.

The Socratic machine, the critic, and the size matrix are shared — this skill keeps only its deltas: → ../_shared/socratic-loop.md · ../_shared/critic.md · ../_shared/size-matrix.md · ../_shared/ask-style.md

Depth governs question volume + autonomy (and which ideation analyses run) → ../_shared/interview-depth.md.

Document prose follows the project's artifact_language setting — section headings, frontmatter and machine tokens stay English → ../_shared/artifact-language.md.

Owner

PM + Tech Lead (co-authors). PM drives goals / non-goals / KPIs; Tech Lead drives context patterns and the acceptance-criteria coverage.

Inputs

• <slug> — kebab-case feature slug.
• (Optional) CONTEXT.md — the two-level glossary: read both repo-root (project-wide) and docs/features/<slug>/CONTEXT.md (feature-scoped); per-feature wins on conflict → ../glossary/SKILL.md. If present, its roles/terms are canonical and override anything that contradicts them.
• docs/features/<slug>/.size — depth hint (MVP vs Full per the size matrix). Read if present; established here if absent (step 1 classifies + writes it), so downstream stages never silently default to M. classify-size re-classifies when scope changes.
• (Optional) prior notes / a reference module / a ticket the user already has.

Protocol

1. Ensure the settings file (first thing, after this skill's own gate). If .claude/sdd.local.md is absent, create it now from the canonical template — documented defaults + the self-documenting body — and patch .gitignore; if it exists, read it and never overwrite. The one procedure lives in ../_shared/settings-file.md. Creating is unconditional; changing values is only ever offered by config. Say one line: «.claude/sdd.local.md created with documented defaults — /sdd:config to tune it». Then read context + set the interview depth. If a CONTEXT.md exists (read both repo-root and docs/features/<slug>/ — per-feature wins on conflict), load its ## Glossary as session state (canonical roles + terms). If .size exists, read it to size the spec's depth; if it's absent, establish it now — run the classify-size protocol inline (the canon: ../classify-size/SKILL.md + the mapping in ../_shared/size-matrix.md); the four signals fold into one bundled AskUserQuestion here (at easy depth, take the matrix default and record it in the assumptions ledger), and write docs/features/<slug>/.size + .route (the route defaults from the size — XS/S→quick, M→standard, L/XL→full — and is confirmed in the same bundled question, per the Routes table in ../_shared/size-matrix.md) — so every later stage reads a real size instead of silently defaulting to M (the gap that otherwise surfaces only at plan-tests). classify-size stays the utility to re-classify when scope changes. If docs/architecture-map.md exists (from survey), read it so the spec is architecture-aware — it informs §1 Context, §2 Constraints, and §3 Non-goals (what the existing system already does / can't do). Absent → suggest running survey first, but proceed (the spec is product-level and can be captured without it). Do not leak the map's tech into §5 AC — AC stay business-observable; the map shapes constraints, not acceptance criteria. Then set the interview depth (the opening question): read interview_depth from the settings file ensured in the first sentence of this step (else default medium), and — unless a --depth=easy|medium|hard arg was passed (which skips the question) — ask ONE depth-selection AskUserQuestion phrased per ../_shared/ask-style.md, with the saved/medium value as the «(Recommended)» first option, overridable per run. The chosen level governs the step-2 deep-dive volume, the step-3 ideation suite, and the step-7 Socratic volume → ../_shared/interview-depth.md. (Completeness — §5's 5-type AC floor — is unaffected by depth.)
2. Capture the idea (interview front). One AskUserQuestion for the raw idea in 1–3 sentences (persist verbatim as the baseline). Then a Socratic deep-dive across problem clarity / success criteria / constraints / strategic fit, delivered in batches of 2–3 — its volume scales with the depth dial (easy: only the few un-inferable ones, then a stated-assumptions ledger; medium: 3–5; hard: walk every angle, foreground each trade-off). Phrase every question per ../_shared/ask-style.md.
3. Ideation suite (depth-gated, named subagents). Run the ideation analyses as named-subagent dispatches gated by the interview-depth dial (size as a secondary trimmer) → ./references/ideation.md: easy → skip the suite (deep-dive only; the chosen approach is recorded as a ledger assumption); medium → researcher (sdd:researcher, competitive/web) + devils-advocate (sdd:devils-advocate, failure-mode mode); hard → full suite researcher + strategist (sdd:strategist, 3 approaches) + analyst (sdd:analyst, multi-perspective) + devils-advocate, then the Claude-proposed RICE/feasibility confirm. Analyses stay product-level (no tech names — that's design); the confirmed recommendation becomes §1 ¶3. Dispatch with subagent_type: "sdd:<name>" per ../_shared/agent-roster.md (general-purpose fallback); researcher needs web — accept its RESEARCH_LIMITED output as a noted gap if web is unavailable.
4. Reconcile the glossary in-flow (a hard rule, at every depth). On every new or unknown domain term that surfaces in the interview or the draft, invoke glossary <slug> for it immediately — compare it against CONTEXT.md and add/update the definition before continuing. By the time the spec is written, every §4 role and §5 domain term is already glossary-canonical; the glossary is never a deferred batch. (Plan-mode nuance: still decide add/update per term in-flow; if writes are blocked until the spec write-point, persist the reconciled terms together with the spec, but never skip the per-term compare.)
5. Ask which extra channels to read (multi-select AskUserQuestion): reference module code / project docs / MCP-Atlassian (Confluence/Jira) / knowledge-base / none. For each picked channel ask the specific path/query — no silent broad scans.
6. Read the template + draft §1–§8. Read ./templates/spec.md (its <!-- instruction --> comments are the per-section contract). Draft per ./references/draft-generation.md: per-section sources, the 5 AC coverage types (happy / error / authorization / domain invariant / cross-context), and the stack-agnostic forbidden-token rule for acceptance criteria.
7. Socratic validation. Walk §4 US → §5 AC → §6 NFR → §7 KPI with the shared 4-state machine (per-decision question volume scales with the depth dial — at easy, the un-asked decisions land in the assumptions ledger for a batch veto). Specify delta → ./references/socratic.md: AC has a 5th option «Add another AC»; the §5 coverage gate enforces two floors after drops/OQ-migrations — (a) ≥1 AC of each of the 5 coverage types, and (b) ≥1 AC per retained §4 user story (regenerate/add a replacement if a type or a user story is left empty). Both are floors, not dials — enforced at every depth; only the question volume scales. The (b) floor closes the §4→§5 link so the downstream sequences use-case coverage + review trace can't be undermined by a user story that lost its only AC. Maintain the edits-log.
8. Critic + write + commit. Dispatch the critic agent — subagent_type: "sdd:critic" (model per judgment_model, effort high — xhigh on L/XL via CLAUDE_CODE_EFFORT_LEVEL; clean-isolated context per ../_shared/agent-roster.md) — with the specify delta in ./references/critic.md (over ../_shared/critic.md) — inline the draft + edits-log, it Reads CONTEXT.md + the idea source itself. Resolve findings via AskUserQuestion (Accept revert / Accept amendment / Override-with-rationale → §1 ¶4 bullet). Run the forbidden-token regex scan as the F6 backstop. On pass, write docs/features/<slug>/spec.md (glossary already reconciled in-flow per step 4) and propose commit spec: <slug>. Register on the roadmap: in docs/roadmap.md (via roadmap) set the matching step's Status: spec'd and link this feature folder; no matching step → append one (source anchor = this spec). (If there's no roadmap yet, skip — it's optional.) Then emit the stage-handoff block per ../_shared/handoff.md — What I did + Review (spec.md, .size, .route) + Run next — resolve the next stage per .route (the Routes table in ../_shared/size-matrix.md; route-resolved variant in handoff.md): forward /sdd:clarify <slug>; clarify's N/A condition = zero §8 open questions and no AC flagged ambiguous, skip target /sdd:ux-flows <slug> (on quick — auto-skip with the reason + inverted ↳ or; on standard — offer the ↳ or; on full — no skip line). When clarify is legally skipped, carry the next condition forward: evaluate ux-flows' N/A condition too (no human-facing UI — every §4 actor a system/service, or the repo has no UI at all, per ../_shared/size-matrix.md) → holds ⇒ the skip target becomes /sdd:design <slug>. (If critic is unavailable, fall back to a general-purpose Agent with the same delta.)