spec-driven-development

Creates structured specifications before coding through a gated four-phase workflow.

Updated Jul 1, 2026
One-click install
npx skills add https://github.com/raishoemi/traffic-sim-v2 --skill spec-driven-development-raishoemi
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec-driven-development
Source: https://github.com/raishoemi/traffic-sim-v2/tree/main/.github/skills/spec-driven-development
Command: npx skills add https://github.com/raishoemi/traffic-sim-v2 --skill spec-driven-development-raishoemi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Starting to code without clear requirements leads to rework, hidden assumptions, and misaligned expectations. This Skill enforces writing a reviewed specification before any implementation begins. ## Core Features & Use Cases - Gated Four-Phase Workflow: Progresses through Specify, Plan, Tasks, and Implement phases, each requiring human review before advancing. - Structured Spec Template: Covers objective, commands, project structure, code style, testing strategy, and Always/Ask First/Never boundaries. - Assumption Surfacing: Forces explicit listing of assumptions and reframes vague requirements into testable success criteria. - Use Case: When asked to build a new feature with only a vague idea, use this Skill to draft a spec document, get it approved, break it into dependency-ordered tasks, and only then implement. ## Quick Start Ask the agent to write a specification for the new feature before writing any code, following the spec-driven development workflow.

Frequently Asked Questions about spec-driven-development

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a specification before coding a new feature?

Follow the four-phase gated workflow: Specify, Plan, Tasks, Implement. Write a spec covering objective, commands, project structure, code style, testing strategy, and boundaries, then get human approval before advancing to planning.

What should a software specification document include?

A spec should cover six core areas: objective, executable commands, project structure, code style with examples, testing strategy, and three-tier boundaries (Always do, Ask first, Never do). Add success criteria and open questions.

When should I skip writing a spec?

Skip the full spec process for single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. Even simple tasks benefit from a two-line spec with acceptance criteria.

How do I handle vague requirements like make it faster?

Reframe vague requirements into concrete, testable success criteria. For example, translate make the dashboard faster into specific targets like LCP under 2.5 seconds on 4G, then confirm those targets with the human.

Why surface assumptions before writing a spec?

Assumptions are the most dangerous form of misunderstanding in requirements. Listing them explicitly before writing spec content lets the human correct wrong assumptions immediately instead of discovering them after implementation.