spec-driven-development

Creates structured specifications through a gated Specify-Plan-Tasks-Implement workflow before coding.

3|Updated Jul 28, 2026
One-click install
npx skills add https://github.com/marcmarti9/agentit --skill spec-driven-development-marcmarti9
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: spec-driven-development
Source: https://github.com/marcmarti9/agentit/tree/main/skills/spec-driven-development
Command: npx skills add https://github.com/marcmarti9/agentit --skill spec-driven-development-marcmarti9

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Starting to code from vague or ambiguous requirements leads to rework, hidden assumptions, and features nobody asked for. This Skill forces a written, human-approved specification before any implementation, turning unclear ideas into testable success criteria. ## Core Features & Use Cases - Gated Four-Phase Workflow: Moves through Specify, Plan, Tasks, and Implement phases, each requiring human review before advancing. - Capability Decomposition: Detects when one request bundles several independently testable capabilities and proposes a capability map with module ids, dependencies, and build order before any spec is written. - Assumption Surfacing and Reframing: Lists assumptions explicitly and translates vague requirements (e.g. "make it faster") into concrete, measurable success criteria. - Use Case: When asked to build a new billing feature with unclear requirements, use this Skill to draft a spec covering objective, commands, structure, style, testing, and boundaries, get it approved, then break it into dependency-ordered tasks. ## Quick Start Ask the agent to write a specification for the new feature before writing any code, including success criteria and boundaries for review.

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 software specification before coding?▼

Write a spec covering six areas: objective, commands, project structure, code style, testing strategy, and boundaries. Surface your assumptions first, reframe vague requirements into testable success criteria, and get human approval before moving to planning and implementation.

How to break down a large feature into modules before specifying?▼

Detect when one requirement bundles several independently testable capabilities, then propose a capability map with stable kebab-case module ids, one-directional dependencies, and a build order. After human approval, run the full spec workflow per module in dependency order.

When should I skip writing a spec for a code change?▼

Skip the full spec for single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. Simple tasks still benefit from a two-line spec with acceptance criteria, but the gated workflow targets material work.

Can I use this workflow with OpenSpec or other spec tools?▼

Yes, the workflow is format-agnostic. If the project already uses OpenSpec or another specification system, keep that tool's artifact format and storage conventions; this workflow owns the clarification, content, and approval gates.

Why does coding without a spec cause rework?▼

Code without a spec relies on silent assumptions about requirements, which surface as misunderstandings only after implementation. A short approved spec with concrete success criteria exposes those misunderstandings before any code is written.