Unified spec-driven development workflow. Use for creating, designing, planning, executing, and critiquing specifications. Triggers on "spec", "create spec", "design spec", "plan spec", "execute spec", "critique spec", "requirements", or spec numbers like "spec 001".
Uses a structured spec-driven workflow for complex, multi-session work. Triggers on commands like "create spec", "plan spec", or "execute spec 001" to guide implementation from requirements through design, planning, and execution with optional adversarial critique.
/plugin marketplace add a3lem/my-claude-plugins/plugin install spec-driven-dev@my-claude-pluginsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
RULES.mdreferences/critique.mdreferences/design.mdreferences/execution.mdreferences/new.mdreferences/requirements.mdreferences/tasks.mdscripts/next-spec-number.shtemplates/compact.mdtemplates/design.mdtemplates/notes/template.mdtemplates/requirements.mdtemplates/tasks.mdA structured workflow where specifications are the source of truth. Implementation follows from specs, not the other way around.
Always read RULES.md first - it contains immutable principles that apply at all times.
Analysis → Design → Plan → Execute → (Critique)
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
requirements design tasks code verdict
(opt) (on-demand)
Each phase produces a specification artifact. notes/ can be created during any phase when there's information worth recording (research, exploration findings, incidental insights, failed approaches).
SDD is valuable for complex, multi-session, or collaborative work. For trivial changes (single-line fixes, routine refactors, obvious implementations), skip SDD and implement directly. See RULES.md > When to Use Spec-Driven Development for detailed guidance.
Interactive mode (default): Use AskUserQuestion at each phase to gather input and confirm decisions.
High agency mode: When the user requests autonomous operation (e.g., "work on this until done", "implement this end-to-end", "full autopilot"), iterate through phases without prompting:
intra-spec mode) to validate requirementsintra-spec + spec-code modes) to validate planall modes) before marking completeIn high agency mode, only pause for user input when hitting a genuine ambiguity that cannot be resolved through reasoning, or when the critic escalates after 5 rounds.
specs/NNN-[slugified-description]/
├── requirements.md # What we're building (FR-/NFR- with EARS notation)
├── design.md # How we're building it (optional)
├── tasks.md # Implementation plan + checklist with [NEXT] markers
└── notes/ # Optional: created during any phase when needed
├── research.md # Exploration findings, links, citations
├── implementation.md # Execution-phase learnings, gotchas
└── ... # Any files that add new information
Spec files include status field in frontmatter: active, stale, archived, or superseded. See RULES.md for details.
Specs are numbered sequentially starting at 001. When user says "spec 3", look for specs/003-*/ (directory) or specs/003-*.md (compact).
For small, focused work, use a single-file spec instead of a directory:
specs/NNN-brief-description.md # Single file instead of directory
Use compact format when:
Use directory format when:
Compact specs contain requirements + tasks in one file. See templates/compact.md.
| Command | Action |
|---|---|
/new [description] | Specify - Create new spec (compact or directory) |
/refine [instruction] | Refine - Update requirements, design, or tasks |
/execute [spec nr] | Execute - Implement the spec |
For /refine, determine which file to update based on the instruction:
requirements.mddesign.mdtasks.mdIf unclear, use AskUserQuestion to clarify which aspect to refine.
REQUIRED reading:
If spec already created, move on to next phase!
Create or refine requirements.
MANDATORY: Read references/requirements.md before proceeding.
Completion:
intra-spec mode) before proceedingCreate or refine architectural decisions.
MANDATORY: Read references/design.md before proceeding.
When to skip: Simple features, bug fixes, obvious implementations.
Completion: Inform user they can continue with plan.
Create implementation plan and progress checklist.
MANDATORY: Read references/tasks.md before proceeding.
Completion:
intra-spec + spec-code modes) before proceedingImplement the specification.
MANDATORY: Read references/execution.md before proceeding.
Completion:
all modes) before marking spec completeOn-demand adversarial review. Delegate to spec-critic agent.
The critic acts as a senior engineer stand-in, challenging assumptions and demanding proof. It engages in multi-turn dialogue until satisfied (max 5 rounds).
Critique modes:
intra-spec - Coherence within the spec (no contradictions between spec files)spec-code - Alignment with codebase (assumptions validated, conventions followed)inter-spec - Consistency across specs (no conflicts with other active specs)all - Run all three modesVerdict levels:
approved - No issues, may proceedapproved-with-reservations - Minor issues, may proceedneeds-work - Significant issues, must addressblocked - Critical problems, cannot proceedInvocation: "Consult with the spec-critic agent to review [spec path] (critique mode: [mode])"
Multi-turn dialogue:
When critic returns needs-work or blocked:
approved or max rounds reachedWhen to invoke critic (high agency mode):
intra-specintra-specintra-spec + spec-codeallReference: references/critique.md for detailed checklists
Spec-driven development appears sequential but all phases can be revisited:
notes/ and proceedThis skill delegates critique to a specialized agent:
| Agent | Model | Purpose |
|---|---|---|
| spec-critic | sonnet | Adversarial reviewer; challenges assumptions, validates alignment |
All templates are in templates/:
requirements.md - Full requirements (directory format)design.md - Design decisions (directory format)tasks.md - Implementation plan (directory format)notes/template.md - Starting point for note files (any phase)compact.md - Single-file spec (compact format)| Phase | Output | Key Tools |
|---|---|---|
| Analysis | requirements.md | AskUserQuestion |
| Design | design.md | AskUserQuestion |
| Plan | tasks.md | Glob, Grep, Read |
| Execute | code (+ notes/ if needed) | Bash, tests |
| Critique | verdict + findings | spec-critic |
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.