spec-driven-development

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

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/Avistian/nba --skill spec-driven-development-avistian
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: spec-driven-development
Source: https://github.com/Avistian/nba/tree/main/.cursor/skills/spec-driven-development
Command: npx skills add https://github.com/Avistian/nba --skill spec-driven-development-avistian

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Starting to code with vague or ambiguous requirements leads to rework, misaligned expectations, and architectural mistakes. This Skill forces requirements into a written, human-reviewed specification before any implementation begins. ## Core Features & Use Cases - Gated Four-Phase Workflow: Enforces Specify → Plan → Tasks → Implement, with human review required before advancing between phases. - Six-Area Spec Template: Covers objective, commands, project structure, code style, testing strategy, and Always/Ask-First/Never boundaries. - Assumption Surfacing & Reframing: Lists assumptions explicitly and converts vague requests like "make it faster" into testable success criteria. - Use Case: When asked to build a new feature with unclear requirements, use this Skill to draft a spec with concrete acceptance criteria, get human approval, break it into dependency-ordered tasks, then implement incrementally. ## Quick Start Ask the agent to write a specification for the new feature before writing any code, including success criteria 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 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.

What is spec-driven development workflow?▼

Spec-driven development is a gated four-phase workflow: Specify, Plan, Tasks, Implement. Each phase requires human review before advancing, ensuring the written spec remains the shared source of truth between the engineer and stakeholders.

When should I not write a specification?▼

Skip the full spec for single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. Even simple tasks benefit from a two-line spec with acceptance criteria, but lengthy documents are unnecessary.

How do I turn vague requirements into acceptance criteria?▼

Reframe vague requests into specific, measurable conditions. For example, "make the dashboard faster" becomes LCP under 2.5 seconds on 4G, initial data load under 500ms, and CLS under 0.1, then confirm the targets with the requester.

How do I keep a specification up to date during development?▼

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 that implements it.