This skill should be used when the user mentions creating a new spec.
This skill inherits all available tools. When active, it can use any tool Claude has access to.
templates/design.mdtemplates/notes.mdtemplates/requirements.mdtemplates/tasks.mdThis skill guides the creation and population of a new specification directory.
Spec creation is a two-phase process:
This skill activates when:
/new-spec, "create a spec for...")Run the scaffolding script to create the directory structure:
python ${CLAUDE_PLUGIN_ROOT}/scripts/new_spec.py "Feature description"
This creates:
specs/NNN-feature-description/
├── requirements.md
├── design.md
├── tasks.md
└── notes.md
Use AskUserQuestion to gather concrete information before populating the spec files. Ask questions in batches to avoid overwhelming the user.
Ask about the problem and success criteria:
Question: "What problem does this feature solve?"
Header: "Problem"
Options:
- User-facing issue (describe the user pain point)
- Technical debt (describe the current limitation)
- New capability (describe what becomes possible)
Question: "What must be true for this feature to be considered complete?"
Header: "Success"
Options:
- Functional criteria (behavior-based acceptance)
- Performance criteria (speed, scale requirements)
- Integration criteria (works with existing systems)
Ask about architectural approach:
Question: "What's the high-level approach for implementing this?"
Header: "Approach"
Options:
- Extend existing code (modify current implementation)
- New component (create standalone module)
- Replace existing (rewrite current solution)
Question: "Are there key constraints or decisions already made?"
Header: "Constraints"
Options:
- Technology constraints (must use X library/framework)
- Compatibility requirements (must work with existing Y)
- No specific constraints
After gathering information, populate each file using the templates.
Use EARS notation for requirements. See ${CLAUDE_PLUGIN_ROOT}/shared/references/ears-notation.md for syntax.
Template structure:
# Requirements: [Feature Name]
## Problem Statement
[Description of the problem being solved]
## User Stories
- As a [role], I want [capability] so that [benefit]
## Success Criteria
WHEN [condition]
THE SYSTEM SHALL [expected behavior]
- [ ] Criterion 1 (testable, specific)
- [ ] Criterion 2
Template structure:
# Design: [Feature Name]
## Approach
[High-level description of how this will be implemented]
## Key Decisions
| Decision | Rationale |
|----------|-----------|
| Decision 1 | Why this choice |
## Components
- Component A: [responsibility]
- Component B: [responsibility]
## Data Flow
[Description or diagram of how data moves through the system]
Template structure:
# Tasks: [Feature Name]
## Plan
[Strategic approach - what phases, what order]
## Progress
### Setup
- [ ] Task 1
- [ ] Task 2
### Implementation
- [ ] Task 3
- [ ] Task 4
### Validation
- [ ] Write tests
- [ ] Manual testing
- [ ] Documentation
Template structure:
# Notes: [Feature Name]
## Implementation Details
[Technical notes added during implementation]
## Learnings
[Insights discovered during implementation]
${CLAUDE_PLUGIN_ROOT}/shared/references/spec-driven-development.md - Philosophy and conventions of this approach${CLAUDE_PLUGIN_ROOT}/shared/references/ears-notation.md - EARS syntax guide for requirementsExample files in templates/:
requirements.md - Requirements structure with EARS notationdesign.md - Design document structuretasks.md - Tasks and progress structurenotes.md - Implementation notes structure