spec-driven-development

Creates structured specification documents in docs/SPEC.md before writing any code.

Updated May 21, 2026
One-click install
npx skills add https://github.com/nicorevo/AI-SDLC-Template --skill spec-driven-development-nicorevo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: spec-driven-development
Source: https://github.com/nicorevo/AI-SDLC-Template/tree/main/.opencode/skills/spec-driven-development
Command: npx skills add https://github.com/nicorevo/AI-SDLC-Template --skill spec-driven-development-nicorevo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It prevents wasted implementation effort caused by ambiguous or missing requirements by forcing a written, human-reviewed specification before any code is produced. ## Core Features & Use Cases - Four-Phase Gated Workflow: Enforces SPECIFY → PLAN → TASKS → IMPLEMENT with human review gates between each phase. - Six-Section Spec Template: Generates docs/SPEC.md covering objective, commands, project structure, code style, testing strategy, and boundaries (Always/Ask First/Never). - Assumption Surfacing: Lists implicit assumptions and reframes vague requirements into testable success criteria before planning. - Use Case: When asked to build a new feature with only a vague description, use this Skill to interview the user, write docs/SPEC.md, produce tasks/plan.md and tasks/todo.md, then hand off to implementation skills. ## Quick Start Ask the agent to write a specification for the new feature and save it to docs/SPEC.md 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?▼

Follow the four-phase gated workflow: specify, plan, tasks, implement. Write a spec covering objective, commands, project structure, code style, testing strategy, and boundaries, save it to docs/SPEC.md, and get human approval before planning.

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 should the specification file be saved?▼

Save the specification to docs/SPEC.md, creating the docs directory if needed. Plans go to tasks/plan.md and task lists to tasks/todo.md, matching the conventions expected by downstream commands.

How do I handle vague requirements like make it faster?▼

Reframe vague requirements into concrete, testable success criteria, such as LCP under 2.5 seconds or load time under 500ms. Confirm these targets with the human before proceeding so the goal is measurable.

What are the limitations of spec-driven development?▼

It adds upfront writing time and is unnecessary for trivial, unambiguous changes. The spec must also be maintained as a living document, since outdated specs lose value when scope or decisions change.