spec-driven-workflow

Run a six-phase spec workflow from requirements to self-review.

Updated Jun 2, 2026
One-click install
npx skills add https://github.com/ano4l/SiteRent --skill spec-driven-workflow-ano4l
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec-driven-workflow
Source: https://github.com/ano4l/SiteRent/tree/main/skills/spec-driven-workflow
Command: npx skills add https://github.com/ano4l/SiteRent --skill spec-driven-workflow-ano4l

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

Spec-driven workflow enforces the practice of writing and obtaining approval for a complete specification before coding any feature. This discipline reduces ambiguity, aligns stakeholders, and creates a contract that links every line of code and test back to a defined requirement.

Core Features & Use Cases

The workflow spans six phases: Gather Requirements, Write Spec, Validate Spec, Generate Tests, Implement, and Self-Review. It also codifies bounded autonomy rules to guide when to escalate questions and how to handle ambiguity. This approach ensures RFC 2119 keyword usage, traceability between requirements and tests, and explicit edge-case coverage to prevent scope creep.

Quick Start

Run the six-phase spec workflow to capture requirements, write and validate the spec, generate tests, implement, and perform a self-review.

Frequently Asked Questions about spec-driven-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is a spec-driven workflow and how does it prevent scope creep?

A spec-driven workflow requires an approved, comprehensive specification before coding to prevent scope creep. It enforces bounded autonomy rules and explicit edge-case coverage across six phases, ensuring traceability from requirements to tests and reducing ambiguity.

How do I generate tests from requirements using a specification workflow?

You generate tests from requirements by following the spec workflow's sequential phases: gather requirements, write the spec, validate it, and generate tests. This creates direct traceability between acceptance criteria and the resulting test cases.

When do I need to use RFC 2119 keywords in software specifications?

You need to use RFC 2119 keywords in software specifications during the spec writing and validation phases. This workflow enforces RFC 2119 keyword usage to codify requirement strictness and ensure bounded autonomy when handling ambiguity.

Does writing a complete specification before coding actually improve traceability?

Writing a complete specification before coding improves traceability by creating a contract that links every line of code and test back to a defined requirement. The workflow validates specs before implementation to maintain this alignment.

What are the limitations of enforcing bounded autonomy in a specification workflow?

The limitation of enforcing bounded autonomy in a specification workflow is the strict requirement for an approved spec before any code is written. This prevents immediate coding but eliminates ambiguity by dictating exactly when to escalate questions.