Skip to content
Back to skills

Spec Driven Development

ASecurity

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.

  • 25 stars
  • 0 votes
  • 0 copies
  • 7 views
  • Added May 27, 2026
developmenttestinggit

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned May 27, 2026

npx -y skills add charlieviettq/awesome-agent-skill --skill spec-driven-development --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Spec Driven Development?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Spec Driven Development
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/charlieviettq-spec-driven-development/badge)](https://www.skillsdirectory.com/skills/charlieviettq-spec-driven-development)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: spec-driven-development
version: 2
description: >
  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.
triggers:
  - "write spec"
  - "PRD"
  - "requirements"
  - "spec before code"
  - "what are we building"
tools: []
mutating: false
priority: normal
---

# 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)

1. **Objective** — user, problem, success criteria
2. **Commands** — build, test, lint, dev (full commands)
3. **Structure** — where code, tests, docs live
4. **Code style** — one example snippet beats paragraphs
5. **Testing** — framework, levels, coverage expectations
6. **Boundaries** — Always / Ask first / Never

## Assumptions block

Before writing the spec, list assumptions and ask for correction:

```text
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 missing
- `planning-and-task-breakdown` — after spec is approved
- `incremental-implementation` — during build

See [reference.md](reference.md) for a lightweight template.

*Workflow patterns inspired by [obra/superpowers](https://github.com/obra/superpowers) (MIT).*

Files in this skill

  • SKILL.md2.1 KB
  • reference.md392 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.