spec-driven-development

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

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents wasted engineering effort caused by ambiguous requirements by forcing a written, human-reviewed specification before any code is written, surfacing assumptions and defining testable success criteria up front. ## Core Features & Use Cases - Gated Four-Phase Workflow: Enforces Specify, Plan, Tasks, and Implement phases, each requiring human review before advancing. - Capability Decomposition: Detects when one request bundles multiple independently testable capabilities and produces a capability map with module ids, dependencies, and build order. - Spec Template & Boundaries: Provides a six-section spec template covering objective, commands, structure, code style, testing, and Always/Ask First/Never boundaries. - Use Case: When asked to build a new multi-module feature like a billing system, use this Skill to decompose it into modules, write per-module specs, and generate an ordered task list before implementation begins. ## Quick Start Ask the agent to write a specification for the new feature you have in mind before any code is written.

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 assumptions explicitly, reframe vague requirements into testable success criteria, and get human approval before implementation begins.

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.

How do I break a large feature into smaller specs?▼

Detect when one requirement bundles independently testable capabilities, then write a capability map listing module ids, dependencies, and build order. After human approval, run the full Specify-Plan-Tasks-Implement cycle per module in dependency order.

What are the limitations of spec-driven development?▼

It adds upfront overhead that is unnecessary for trivial, unambiguous changes like typo fixes. It also depends on human review at each phase, so progress stalls if reviewers are unavailable.

How do I keep a specification up to date?▼

Treat the spec as a living document: update it when decisions or scope change, commit it to version control alongside the code, and reference the relevant spec section in each pull request.