spec-driven-development

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

Updated May 13, 2026
One-click install
npx skills add https://github.com/sapatamuku-creator/mastersapatamuku --skill spec-driven-development-sapatamuku-creator
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: spec-driven-development
Source: https://github.com/sapatamuku-creator/mastersapatamuku/tree/main/releases/v2.7/.agents/skills/spec-driven-development
Command: npx skills add https://github.com/sapatamuku-creator/mastersapatamuku --skill spec-driven-development-sapatamuku-creator

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Starting to code with vague or ambiguous requirements leads to rework, wrong assumptions, and features nobody asked for. This Skill forces a written specification before any implementation, surfacing hidden assumptions and defining testable success criteria up front. ## Core Features & Use Cases - Gated Four-Phase Workflow: Progresses through Specify, Plan, Tasks, and Implement phases, each requiring human review before advancing. - Six-Area Spec Template: Covers objective, commands, project structure, code style, testing strategy, and boundaries (Always/Ask First/Never rules). - Assumption Surfacing: Lists assumptions explicitly and reframes vague requirements like "make it faster" into measurable success criteria. - Use Case: When asked to build a new dashboard feature with unclear requirements, use this Skill to write a spec with concrete acceptance criteria (e.g., LCP under 2.5s), get human approval, then break it into dependency-ordered tasks before writing code. ## Quick Start Ask the agent to write a specification for the new feature before writing any code, covering objectives, commands, structure, style, testing, and boundaries.

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

Start by listing your assumptions explicitly, then write a spec covering six areas: objective, commands, project structure, code style, testing strategy, and boundaries. Have a human review and approve the spec before moving to planning and implementation.

How to handle vague requirements like make the dashboard faster?▼

Reframe vague requirements into concrete success criteria, such as LCP under 2.5 seconds on 4G or initial data load under 500ms. Confirm these targets with the requester before proceeding so you can verify completion objectively.

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

Skip the full spec only for single-line fixes, typo corrections, or changes with unambiguous self-contained requirements. Even simple tasks benefit from a two-line spec with acceptance criteria; anything over 30 minutes of work warrants a spec.

What are the phases of spec-driven development?▼

The workflow has four gated phases: Specify (write the spec), Plan (technical implementation plan saved to tasks/plan.md), Tasks (dependency-ordered task list in tasks/todo.md), and Implement. Each phase requires human review before advancing.

Why keep the spec updated after implementation starts?▼

The spec is a living document that must reflect decision and scope changes discovered during implementation. Commit it to version control and reference it in pull requests so the shared source of truth never diverges from the actual code.