spec-driven-development

Creates structured specifications with gated review phases before writing any code.

665|3|Updated Sep 12, 2026
One-click install
npx skills add https://github.com/rizqinrr/viserys-agent --skill spec-driven-development-rizqinrr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec-driven-development
Source: https://github.com/rizqinrr/viserys-agent/tree/main/skills/spec-driven-development
Command: npx skills add https://github.com/rizqinrr/viserys-agent --skill spec-driven-development-rizqinrr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code written without a specification is guessing. This Skill prevents rework by forcing requirements, assumptions, and success criteria into a written, human-approved spec before any implementation begins. ## Core Features & Use Cases - Gated Four-Phase Workflow: Moves through Specify, Plan, Tasks, and Implement phases, each requiring human review before advancing. - Capability Decomposition: Detects when one request bundles several independently testable capabilities and proposes a capability map with module ids, dependencies, and build order before any spec is written. - Spec Template with Boundaries: Produces specs covering objective, commands, project structure, code style, testing strategy, and Always/Ask First/Never boundaries. - Use Case: When asked to build a new billing feature with vague requirements, use this Skill to surface assumptions, reframe "make it faster" into measurable success criteria, and produce an approved spec before touching code. ## Quick Start Use the spec-driven-development skill to write a specification for the new notification feature before implementing it.

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 spec before starting a new feature?

Follow the four-phase workflow: clarify requirements and assumptions, write a spec covering objective, commands, structure, style, testing, and boundaries, then get human approval before planning tasks. The spec becomes the shared source of truth for implementation.

When should a requirement be split into a capability map?

Decompose when one requirement bundles several independently testable capabilities, such as identity, billing, and notifications, with acceptance criteria that could ship separately. Propose a small module table with dependency direction and build order before writing any module spec.

Can I use this workflow with OpenSpec or other spec tools?

Yes, the workflow is format-agnostic. If the project already uses OpenSpec or another specification system, keep that tool's artifact format and storage conventions; this skill owns the clarification, content, and approval gates.

When should I skip writing a specification?

Skip the full spec for single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. Simple tasks still benefit from a two-line spec with acceptance criteria, but the gated workflow is unnecessary overhead.

How do I turn vague requirements into testable criteria?

Reframe vague instructions into concrete success criteria with measurable targets, such as converting "make the dashboard faster" into LCP under 2.5 seconds and CLS under 0.1. Confirm the reframed targets with the human before proceeding.