spec-driven-development

Writes structured specifications before coding through a four-phase specify-plan-tasks-implement workflow.

2|Updated Jul 25, 2026
One-click install
npx skills add https://github.com/ankaboot-source/boucle --skill spec-driven-development-ankaboot-source
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: spec-driven-development
Source: https://github.com/ankaboot-source/boucle/tree/main/.jcode/skills/spec-driven-development
Command: npx skills add https://github.com/ankaboot-source/boucle --skill spec-driven-development-ankaboot-source

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Starting to code from vague or ambiguous requirements leads to rework, misaligned implementations, and undocumented architectural decisions. This Skill forces clarity upfront by producing a written specification that serves as the shared source of truth before any code is written. ## Core Features & Use Cases - Four-Phase Workflow: Guides work through Specify, Plan, Tasks, and Implement phases, each gated by self-validation checklists. - Structured Spec Template: Covers objective, commands, project structure, code style, testing strategy, and three-tier boundaries (Always / Ask First / Never). - Assumption Surfacing: Explicitly lists assumptions and reframes vague requirements into concrete, testable success criteria. - Use Case: When a new feature request arrives as a one-line issue like "make the dashboard faster", use this Skill to produce a spec with measurable targets (e.g., LCP under 2.5s), a dependency-ordered plan in tasks/plan.md, and a task list in tasks/todo.md before implementation begins. ## Quick Start Ask the agent to write a specification for the new feature described in the issue before writing any code.

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 workflow: Specify, Plan, Tasks, Implement. Write a spec covering objective, commands, project structure, code style, testing strategy, and boundaries, then derive a plan and task list from it before implementing.

What should a good feature specification document include?

A good spec includes six core areas: objective with success criteria, executable commands, project structure, code style with a real snippet, testing strategy, and three-tier boundaries (Always do, Ask first, Never do), plus open questions.

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. Even simple tasks benefit from a two-line spec with acceptance criteria.

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 data load under 500ms. Surface your assumptions explicitly and record unresolved items in the spec's Open Questions section.

Where are the plan and task list files saved?

The implementation plan is saved to tasks/plan.md and the task list to tasks/todo.md, following the /plan command convention. Create the tasks/ directory if it does not exist, since downstream commands expect these paths.