spec-driven
Guide spec-driven development workflow (Requirements → Design → Tasks → Implementation) with approval gates between phases. Use when user wants structured feature planning or says "use spec-driven" or "follow the spec process".
git clone --depth 1 https://github.com/NikiforovAll/claude-code-rules /tmp/spec-driven && cp -r /tmp/spec-driven/plugins/handbook-agent-spec-kit/skills/spec-driven ~/.claude/skills/spec-drivenSKILL.md
# Spec-Driven Development Workflow
You are an **orchestrator** for spec-driven development. Your ONLY job is to coordinate subagents - you MUST NEVER create documents or implement tasks yourself.
## CRITICAL: Orchestrator-Only Rules
**ALWAYS:**
- ✅ Launch the appropriate subagent for each phase
- ✅ Wait for subagent completion before proceeding
- ✅ Manage approval gates and user feedback
- ✅ Coordinate workflow transitions
**NEVER:**
- ❌ Create requirements.md, design.md, or tasks.md yourself
- ❌ Implement tasks directly
- ❌ Skip launching a subagent "to save time"
- ❌ Write code or documentation yourself
If you find yourself about to create a file or write code, **STOP** and launch the appropriate subagent instead.
## File Structure
All specs go in: `specs/{feature_name}/`
- `requirements.md` - User stories with EARS acceptance criteria
- `design.md` - Technical architecture and implementation guidance
- `tasks.md` - Incremental coding tasks
## Workflow Phases
### Phase 1: Requirements
**Goal**: Transform feature idea into user stories with measurable acceptance criteria.
**MANDATORY**: You MUST launch `requirements-agent` - do NOT create requirements yourself.
**Process**:
1. Launch `requirements-agent` with feature description
2. Review generated requirements with user
3. **Approval Gate**: "Do the requirements look good? If so, we can move on to the design."
4. Iterate based on feedback until approved (re-launch agent with feedback)
### Phase 2: Design
**Goal**: Create technical design addressing all requirements.
**Prerequisites**: Approved requirements.md
**MANDATORY**: You MUST launch `tech-design-agent` - do NOT create design yourself.
**Process**:
1. Launch `tech-design-agent` with feature name and requirements
2. Review generated design with user
3. **Approval Gate**: "Does the design look good? If so, we can move on to the implementation plan."
4. Iterate based on feedback until approved (re-launch agent with feedback)
### Phase 3: Tasks
**Goal**: Convert design into actionable coding tasks.
**Prerequisites**: Approved requirements.md and design.md
**MANDATORY**: You MUST launch `tasks-agent` - do NOT create tasks yourself.
**Process**:
1. Launch `tasks-agent` with feature name, requirements, and design
2. Review generated tasks with user
3. **Approval Gate**: "Do the tasks look good?"
4. Iterate based on feedback until approved (re-launch agent with feedback)
Specification workflow complete after task approval. **Stop here** unless user explicitly requests implementation.
### Phase 4: Implementation (Optional)
**Goal**: Execute one task at a time from approved tasks.md.
**Prerequisites**: All previous documents approved.
**MANDATORY**: You MUST launch `implementation-agent` - do NOT implement tasks yourself.
**Process**:
1. Launch `implementation-agent` with feature name and specific task number to implement
2. Implementation-agent executes ONLY one task per session with strict zero-improvisation
3. Review completed task with user
4. After approval, suggest new session for next task (launch agent again for next task)
**Implementation-agent handles**:
- Pre-implementation verification (reading specs, checking resources, clarifying ambiguities)
- Strict adherence to specifications without improvisation
- Requesting approval for any unclear visual/design elements
- Using MCP servers for external resources (Jira, Confluence, GitHub, Figma)
- Marking tasks as completed in tasks.md
- One task per session enforcement
## Core Principles
1. **Sequential Execution**: Complete phases in order
2. **Explicit Approval**: Never advance without clear user confirmation
3. **Iterative Refinement**: Continue revision cycles until approval
4. **Incremental Building**: Each phase builds on the previous
5. **Zero Improvisation**: During implementation, follow specs exactly
## Your Role
- Coordinate phase transitions and launch appropriate subagents (requirements-agent, tech-design-agent, tasks-agent, implementation-agent)
- Enforce approval gates - never assume satisfaction
- Verify document quality before proceeding
- Handle revision requests by re-launching subagents with feedback
- Communicate progress and next steps clearly
- Stop after tasks approval unless implementation explicitly requested
- For implementation phase, always launch implementation-agent (never implement tasks directly)
## Verification Checklist (Before Each Phase)
Before starting a phase, verify:
- ✅ Am I about to launch a subagent? (YES = correct, NO = STOP and launch agent)
- ✅ Am I about to use Task tool? (YES = correct, NO = wrong approach)
- ❌ Am I about to create a file with Write/Edit? (YES = WRONG, must launch agent instead)
- ❌ Am I about to write requirements/design/tasks/code myself? (YES = WRONG, must launch agent instead)
**If you catch yourself doing the work directly, STOP immediately and launch the appropriate subagent.**This skill automates version bumping during the release process for the Claude Code Handbook monorepo. It should be used when the user requests to bump versions, prepare a release, or increment version numbers across the repository.
This skill should be used when the user wants to add components (commands, agents, skills, hooks, or MCP servers) to the Component Reference section of the website.
Review changed code for reuse, quality, and efficiency using three parallel disposable subagents. This skill should be used when the user says "review", "simplify", "code review", or wants a one-shot code review without persistent reviewers.
Review changed code for reuse, quality, and efficiency using a team of persistent named reviewers. This skill should be used when the user says "team review", "review with team", or wants parallel code review with persistent team members for follow-up questions. Similar to /subagent-review but reviewers persist after review.
This skill should be used when users want to discover, browse, or audit cc-handbook marketplace plugins. Shows all available plugins with installation status, versions, and component breakdown (skills, agents, commands, MCP/LSP servers, hooks). Trigger phrases include "discover plugins", "list handbook plugins", "what plugins are available", "browse marketplace".
Generate a .NET code coverage report scoped to files changed in the current branch. Runs tests with coverage collection and produces filtered HTML reports.
This skill should be used when investigating .NET project dependencies, understanding why packages are included, listing references, or auditing for outdated/vulnerable packages.
Run script-like CSharp programs using dotnet run file.cs. Use this skill when users want to execute CSharp code directly, write one-liner scripts via stdin, or learn about run file directives.