spec-driven

Start a new spec-driven development workflow for a feature

Brainstorm a feature idea through conversation until it's ready for /spec

Refine requirements or design for an existing spec

Regenerate tasks from updated spec requirements and design

Show status and progress of current spec

Use this agent for the Requirements and Design phases of spec-driven development. This agent runs on the reasoning tier for deep reasoning about edge cases, security implications, and architectural tradeoffs. Examples: <example> Context: User has started a new spec and needs to create requirements and design. user: "I need to create a spec for user authentication" assistant: "I'll use the spec-planner agent to thoroughly analyze requirements and design the architecture." <commentary> User is starting spec creation. The planner agent uses the reasoning tier to deeply reason about requirements, identify edge cases, and design robust architecture. </commentary> </example> <example> Context: User is running /spec command and entering the requirements phase. user: "/spec payment-processing" assistant: "I'll use the spec-planner agent to carefully work through requirements and design for payment processing." <commentary> Payment processing is security-sensitive. The reasoning tier will catch edge cases and security considerations that faster models might miss. </commentary> </example> <example> Context: User wants to redesign part of their spec. user: "I need to rethink the architecture for our real-time notifications feature" assistant: "I'll use the spec-planner agent to analyze the design with deep reasoning." <commentary> Architectural redesign benefits from the reasoning tier's superior reasoning about tradeoffs and system design. </commentary> </example>

Use this agent to break down a completed spec design into implementation tasks. This agent runs on the standard tier for fast, structured task generation. Examples: <example> Context: User has completed requirements and design, now needs tasks. user: "The requirements and design are done, now break it down into tasks" assistant: "I'll use the spec-tasker agent to create structured implementation tasks from your spec." <commentary> Design is complete. Task breakdown is structured work that the standard tier handles efficiently -- read the spec, generate ordered tasks with dependencies. </commentary> </example> <example> Context: User runs /spec-tasks to regenerate tasks after spec changes. user: "/spec-tasks" assistant: "I'll use the spec-tasker agent to regenerate tasks from the updated spec." <commentary> Task regeneration follows a clear pattern. The standard tier is fast and accurate for this structured decomposition. </commentary> </example> <example> Context: Requirements and design phases just completed within /spec workflow. user: "Let's create the implementation tasks now" assistant: "I'll use the spec-tasker agent to break this down into trackable tasks." <commentary> Transitioning from design to tasks. The tasker agent picks up where the planner left off, using the structured spec to generate tasks. </commentary> </example>

Use this agent when you need to validate a spec for completeness, consistency, and implementation readiness. Examples: <example> Context: User has finished creating a spec and wants to verify it's ready for implementation. user: "I've finished the spec for user-authentication. Can you validate it?" assistant: "I'll use the spec-validator agent to check the spec for completeness and consistency." <commentary> User explicitly requests validation of a completed spec. The agent will check all three files for completeness and cross-reference consistency. </commentary> </example> <example> Context: User is about to start implementation and wants to ensure the spec is solid. user: "Before I start coding, can you check if the spec is complete?" assistant: "Let me validate the spec to ensure it's ready for implementation." <commentary> User wants pre-implementation validation. The agent should check requirements coverage, design completeness, and task traceability. </commentary> </example> <example> Context: User has made changes to requirements and wants to verify consistency. user: "I updated the requirements. Are they still consistent with the design?" assistant: "I'll validate the spec to check for any consistency issues between requirements and design." <commentary> After spec changes, validation ensures documents remain aligned and no gaps were introduced. </commentary> </example>

Implements code for a single task from the spec. Focuses only on writing code, not testing or reviewing.

Verifies that implemented tasks actually work. Uses Playwright for UI testing, runs test suites, and only marks Verified: yes after real verification.

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.