home / skills / nikiforovall / claude-code-rules / spec-driven

This skill coordinates a spec-driven development workflow, launching phase subagents, managing approvals, and guiding transitions to ensure structured feature

npx playbooks add skill nikiforovall/claude-code-rules --skill spec-driven

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
5.1 KB
---
name: spec-driven
description: 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".
---

# 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.**

Overview

This skill orchestrates a spec-driven development workflow that enforces Requirements → Design → Tasks → Implementation with approval gates between phases. I coordinate and launch specialist subagents for each phase, manage iterations, and never create spec files or implement work directly. The skill is ideal when you want a structured, auditable planning process guided by explicit approvals.

How this skill works

I act as the orchestrator: for each phase I launch the appropriate subagent (requirements-agent, tech-design-agent, tasks-agent, implementation-agent), wait for its output, present results for review, and only advance when you explicitly approve. I enforce sequential execution, handle user feedback by relaunching agents with revision instructions, and stop after task approval unless you request implementation. At implementation time I still launch the implementation-agent and never write code or docs myself.

When to use it

  • When you want a repeatable, gated feature planning process (Requirements → Design → Tasks → Implementation).
  • When you say “use spec-driven” or ask to follow the spec process for a feature.
  • When you need clear, reviewable artifacts and explicit approvals before implementation.
  • When multiple stakeholders must review and sign off at each phase.
  • When you want incremental task execution with strict adherence to specs.

Best practices

  • Always provide a clear feature description before launching the requirements-agent.
  • Review each agent’s output carefully and give concrete feedback for revisions.
  • Approve explicitly at each gate — approvals are required to proceed.
  • Avoid asking the orchestrator to write docs or implement tasks; it must launch subagents instead.
  • Use small, focused tasks for implementation to keep iterations fast and verifiable.

Example use cases

  • Planning a new feature that requires cross-team technical review and acceptance criteria.
  • Converting a product idea into measurable user stories with EARS-style acceptance criteria.
  • Producing a detailed implementation plan where tasks are reviewed and approved before coding.
  • Running incremental implementations where each task is executed strictly against the spec.
  • Onboarding teams to a disciplined handoff process from product requirements through implementation.

FAQ

Can the orchestrator write requirements or code if you ask directly?

No. The orchestrator never writes requirements, designs, tasks, or code. It must launch the correct subagent for each artifact or implementation step.

What happens if I don’t approve a phase?

The workflow pauses. Provide feedback and I will relaunch the same subagent with your revision requests until the output is approved.

Can implementation be grouped into multiple tasks per session?

No. Implementation-agent executes one task per session and must follow the spec exactly without improvisation.