spec-driven-development

Creates structured specifications through a gated specify-plan-tasks-implement workflow before coding.

Updated Sep 5, 2026
One-click install
npx skills add https://github.com/nntoan/ultra-omp --skill spec-driven-development-nntoan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: spec-driven-development
Source: https://github.com/nntoan/ultra-omp/tree/main/packages/proflow/skills/spec-driven-development
Command: npx skills add https://github.com/nntoan/ultra-omp --skill spec-driven-development-nntoan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Starting to code with vague or ambiguous requirements leads to rework, misaligned expectations, and undocumented architectural decisions. This Skill enforces writing a reviewed specification before any code, so requirements, boundaries, and success criteria are explicit and shared. ## Core Features & Use Cases - Gated Four-Phase Workflow: Moves through Specify, Plan, Tasks, and Implement phases, each requiring human review before advancing. - Capability Mapping: Decomposes requests bundling several independently testable capabilities into a module map with dependency direction and build order. - Spec Template & Location Policy: Produces specs covering objective, commands, structure, code style, testing, and boundaries, saved to docs/spec/<feature>/SPEC.md. - Use Case: When asked to build a new billing feature with unclear requirements, use this Skill to explore the repository, surface assumptions, draft a spec with testable success criteria, get it approved, then break it into ordered tasks before implementing. ## 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 gated workflow: explore the repository first, surface assumptions, then draft a spec covering objective, commands, project structure, code style, testing strategy, and boundaries. Save it to docs/spec/<feature>/SPEC.md and get human approval before planning or implementing.

When should I use spec-driven development?▼

Use it when starting a new project or feature, when requirements are ambiguous, when changes touch multiple modules, or when a task would take more than 30 minutes. Skip it for single-line fixes or typo corrections where requirements are unambiguous.

How do I split a large feature into multiple specs?▼

When one requirement bundles several independently testable capabilities, create a capability map first with kebab-case module ids, dependency direction, and build order. After human approval, write a separate spec per module at docs/spec/<feature>/<module>/SPEC.md.

Where should specification files be saved in a repository?▼

Save specs to docs/spec/<feature>/SPEC.md, one folder per feature, creating the docs/spec tree if needed. Multi-module initiatives keep the capability map at the feature level and nest module specs underneath it.

What are the limitations of spec-driven development?▼

It adds upfront time, so it is not suited for trivial changes like typo fixes or self-contained one-line edits. It also depends on human review gates, so progress stalls if reviewers do not approve specs, plans, or capability maps.