spec-driven-development

Guides a gated four-phase workflow for writing and validating software specifications before implementation.

4|Updated Jun 19, 2026
One-click install
npx skills add https://github.com/douglance/sdlc-plugin --skill spec-driven-development-douglance
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: spec-driven-development
Source: https://github.com/douglance/sdlc-plugin/tree/main/.rulesync/skills/spec-driven-development
Command: npx skills add https://github.com/douglance/sdlc-plugin --skill spec-driven-development-douglance

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Ambiguous or incomplete requirements cause rework, scope creep, and misaligned implementations. This Skill enforces a gated Specify → Plan → Tasks → Implement workflow so significant changes start from a validated, evidence-backed specification instead of assumptions. ## Core Features & Use Cases - Gated Four-Phase Workflow: Progresses through Specify, Plan, Tasks, and Implement phases, each requiring human review before advancing. - Evidence-Based Specification: Requires citing exact path:line references for repository claims, separating observations from inferences and decisions, and recording prior-art searches. - Structured Spec Template: Covers six core areas — Objective, Commands, Project Structure, Code Style, Testing Strategy, and three-tier Boundaries (Always / Ask First / Never). - Use Case: When starting a multi-module feature that would take more than 30 minutes, use this Skill to surface assumptions, reframe vague requirements into testable success criteria, and produce a version-controlled spec before writing code. ## Quick Start Ask the agent to write a specification for your new feature using the spec-driven development workflow before any implementation begins.

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 implementation?▼

Follow the four-phase gated workflow: Specify with clarifying questions and evidence, Plan the technical approach, break work into Tasks with acceptance criteria, then Implement. Each phase requires human review before advancing to the next.

What should a good feature spec document include?▼

Cover six core areas: Objective, executable Commands, Project Structure, Code Style, Testing Strategy, and three-tier Boundaries (Always do, Ask first, Never do). Add measurable success criteria, evidence citations, and open questions.

When should I not use spec-driven development?▼

Skip it for single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. The workflow is designed for changes touching multiple files, architectural decisions, or tasks exceeding roughly 30 minutes.

How do I turn vague requirements into testable criteria?▼

Reframe each vague requirement as concrete success criteria with measurable thresholds, such as LCP under 2.5 seconds or data load under 500ms, then confirm the targets with the human before proceeding.

Why does the spec require path:line evidence citations?▼

Citing exact repository locations grounds requirements in observed prior art, separates observations from inferences and decisions, and prevents the agent from silently inventing conventions that do not exist in the codebase.