Spec driven development
Skill charlieviettq/awesome-agent-skill/.claude/skills/spec-driven-development
Curated skill pack for LLM agents in engineer and science workflow (Cursor & Claude ready).
npx -y skills add charlieviettq/awesome-agent-skill --skill spec-driven-developmentAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 22 stars22 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Write a structured spec before significant implementation—objective, commands, boundaries, testing, and success criteria. Use when starting a feature, project, or multi-file change without a written spec.
SKILL.md
1.9 KB, 390 tokens by cl100k_base, as published. Nobody here has run it
Spec-driven development
When to use
- New feature, project, or significant change
- Requirements ambiguous or multi-file scope
- Architectural decision needed before code
When not to use
- Single-line fixes, typos, obvious one-file changes
Gated workflow
SPECIFY -> PLAN -> TASKS -> IMPLEMENT
Do not implement until spec (or explicit assumptions) is agreed.
Chunked approval
- Present spec sections in digestible chunks (objective, boundaries, testing) when scope is large
- Ask for explicit approval or corrections per chunk before moving to plan/tasks
- Do not treat silence as sign-off
Spec sections (minimum)
- Objective — user, problem, success criteria
- Commands — build, test, lint, dev (full commands)
- Structure — where code, tests, docs live
- Code style — one example snippet beats paragraphs
- Testing — framework, levels, coverage expectations
- Boundaries — Always / Ask first / Never
Assumptions block
Before writing the spec, list assumptions and ask for correction:
ASSUMPTIONS:
1. ...
2. ...
-> Correct me or I proceed with these.
Success criteria
Reframe vague asks into testable conditions (metrics, dates, thresholds).
Living document
Update spec when scope or decisions change; link spec sections in PRs.
Related
clarify-underspecified— when spec inputs are missingplanning-and-task-breakdown— after spec is approvedincremental-implementation— during build
See reference.md for a lightweight template.
Workflow patterns inspired by obra/superpowers (MIT).
What ships with it: 1 file
392 B alongside SKILL.md
- reference.md392 B