spec-driven
Scannednpx machina-cli add skill NikiforovAll/claude-code-rules/spec-driven --openclawSpec-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 criteriadesign.md- Technical architecture and implementation guidancetasks.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:
- Launch
requirements-agentwith feature description - Review generated requirements with user
- Approval Gate: "Do the requirements look good? If so, we can move on to the design."
- 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:
- Launch
tech-design-agentwith feature name and requirements - Review generated design with user
- Approval Gate: "Does the design look good? If so, we can move on to the implementation plan."
- 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:
- Launch
tasks-agentwith feature name, requirements, and design - Review generated tasks with user
- Approval Gate: "Do the tasks look good?"
- 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:
- Launch
implementation-agentwith feature name and specific task number to implement - Implementation-agent executes ONLY one task per session with strict zero-improvisation
- Review completed task with user
- 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
- Sequential Execution: Complete phases in order
- Explicit Approval: Never advance without clear user confirmation
- Iterative Refinement: Continue revision cycles until approval
- Incremental Building: Each phase builds on the previous
- 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.
Source
git clone https://github.com/NikiforovAll/claude-code-rules/blob/main/plugins/handbook-agent-spec-kit/skills/spec-driven/SKILL.mdView on GitHub Overview
Acts as the orchestrator for spec-driven development, coordinating subagents for Requirements, Design, and Tasks (with an optional Implementation). It never creates docs or implements tasks itself, and it manages approval gates between phases. Use it when you want structured feature planning with explicit phase transitions.
How This Skill Works
It always launches the appropriate subagent for each phase (requirements-agent, tech-design-agent, tasks-agent, and optionally implementation-agent), waits for their completion, and then requires user approval before proceeding. It enforces the rule to never write requirements, design, tasks, or code itself, and handles iterative feedback until a phase is approved.
When to Use It
- When you need structured feature planning with clear acceptance criteria
- When the user says 'use spec-driven' or 'follow the spec process'
- When you want explicit approval gates between Requirements, Design, and Tasks
- When coordinating work across multiple subteams via specs
- When you want to prevent drafting documents or implementing tasks yourself and rely on agent-driven phases
Quick Start
- Step 1: Provide the feature name and description; trigger requirements-agent to generate requirements
- Step 2: Review requirements with the user and obtain approval to proceed to design; trigger tech-design-agent
- Step 3: Review the design, obtain approval, then trigger tasks-agent to convert design into actionable tasks
Best Practices
- Always use the correct phase agents (requirements-agent, tech-design-agent, tasks-agent, implementation-agent) for each phase
- Clearly articulate acceptance criteria at each approval gate and document feedback
- Keep specs under specs/{feature_name}/ and reference them in phase transitions
- Log feedback and re-launch agents with specific feedback rather than starting from scratch
- Do not bypass gates; move forward only after explicit user approval
Example Use Cases
- Launch a spec-driven workflow to add a new checkout flow with requirements and design docs
- Apply spec-driven gates to a complete onboarding redesign
- Introduce an analytics/events tracking plan using Requirements → Design → Tasks
- Implement a feature-flag governance flow with phased approvals
- Migrate authentication to a new provider using the spec-driven process