From spec-driven
This skill should be used when the user asks to "create a spec", "write requirements", "design a feature", "plan implementation", "use EARS notation", "create user stories", "break down tasks", "write a PRD", "technical specification", or mentions "spec-driven development", "feature spec", "requirements phase", "design phase", or "tasks phase". Provides structured 3-phase workflow for feature development.
npx claudepluginhub habib0x0/spec-driven-plugin --plugin spec-drivenThis skill uses the workspace's default tool permissions.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
A structured approach to feature development through four phases: Brainstorm, Requirements, Design, and Tasks. This methodology prevents ad-hoc coding by ensuring proper planning before implementation.
Spec-driven development transforms vague feature ideas into formal, traceable specifications:
Feature Idea → Brainstorm (Conversation) → Requirements (EARS) → Design (Architecture) → Tasks (Trackable)
Before formalizing requirements, use /spec-brainstorm to explore the idea through conversation.
/spec-brainstorm [idea]/spec <feature-name>The brainstorm phase is optional — if you already know exactly what you want, skip straight to /spec.
All spec files are stored in .claude/specs/<feature-name>/:
requirements.md - User stories with EARS acceptance criteriadesign.md - Architecture, components, data flowtasks.md - Implementation tasks synced to Claude Code todosCapture WHAT the system should do using EARS (Easy Approach to Requirements Syntax).
Structure requirements as testable statements:
WHEN [condition/trigger]
THE SYSTEM SHALL [expected behavior]
Examples:
WHEN a user submits a login form with valid credentials
THE SYSTEM SHALL authenticate the user and redirect to dashboard
WHEN a user submits invalid form data
THE SYSTEM SHALL display inline validation errors without page reload
WHEN an API request fails after 3 retries
THE SYSTEM SHALL display a user-friendly error message and log the failure
### US-1: [Story Title]
**As a** [user role]
**I want** [goal/desire]
**So that** [benefit/value]
#### Acceptance Criteria (EARS)
1. WHEN [condition]
THE SYSTEM SHALL [behavior]
For detailed EARS patterns and examples, consult references/ears-notation.md.
Define HOW the system will implement the requirements.
For detailed design patterns, consult references/design-patterns.md.
Break down the design into discrete, trackable implementation tasks.
### T-1: [Task Title]
- **Status**: pending | in_progress | completed
- **Wired**: no | yes | n/a
- **Verified**: no | yes
- **Requirements**: US-1, US-2
- **Description**: [Detailed description]
- **Acceptance**: [How to verify completion]
- **Dependencies**: T-0 | none
Organize tasks into logical phases:
For detailed task breakdown strategies, consult references/task-breakdown.md.
After planning is complete, execute the spec autonomously using the provided scripts.
Run one task at a time:
${CLAUDE_PLUGIN_ROOT}/scripts/spec-exec.sh --spec-name <name>
Each run picks the highest-priority pending task, implements it, tests it, updates the spec, and commits.
Run all tasks in a loop:
${CLAUDE_PLUGIN_ROOT}/scripts/spec-loop.sh --spec-name <name> --max-iterations 50
The loop re-reads spec files each iteration, detects completion via <promise>COMPLETE</promise>, and stops when all tasks are done.
| Command | Description |
|---|---|
/spec-exec | Run one implementation iteration |
/spec-loop | Loop until all tasks complete |
Create specs in the project's .claude/specs/ directory:
project/
├── .claude/
│ └── specs/
│ └── user-authentication/
│ ├── requirements.md
│ ├── design.md
│ └── tasks.md
└── src/
Use the /spec <feature-name> command to start a new spec with interactive guidance through all three phases.
After completing the Tasks phase, sync to Claude Code todos:
For each task in tasks.md:
TaskCreate with subject, description, and dependencies
When implementing features, Claude automatically includes relevant spec files as context. This ensures implementation stays aligned with requirements.
Use /spec-refine to update requirements or design. Changes cascade:
Templates are available at ${CLAUDE_PLUGIN_ROOT}/templates/:
requirements.md - Requirements template with EARS formatdesign.md - Design document templatetasks.md - Task tracking template| Phase | Focus | Output | Key Question |
|---|---|---|---|
| Requirements | WHAT | User stories + EARS | What should it do? |
| Design | HOW | Architecture docs | How will it work? |
| Tasks | WHEN | Task list + todos | What's the sequence? |
For detailed guidance on each phase:
references/ears-notation.md - Complete EARS patterns and examplesreferences/design-patterns.md - Architecture documentation patternsreferences/task-breakdown.md - Task decomposition strategies/spec <name> - Start new spec/spec-refine - Update existing spec/spec-tasks - Regenerate tasks/spec-status - View progress/spec-validate - Validate completeness