Spec Workflow
Use the smallest spec artifact that prevents misunderstanding.
When To Use
- New project or product idea.
- New feature or behavior change.
- Ambiguous bugfix.
- High-risk change touching auth, money, data, security, migrations, or shared contracts.
- User asks for specs, requirements, planning, task breakdown, or clearer agent guidance.
Tiny mechanical edits may use an inline spec brief instead of specs/<id-slug>/.
Flow
- Spec: what and why only. No stack choices or implementation details.
- Clarify: ask until no high-impact
[NEEDS CLARIFICATION]remains. - Plan: translate approved spec into technical approach and validation.
- Tasks: write ordered, test-first tasks with parallel-safe
[P]markers. - Implement: only after spec, plan, and tasks are stable.
- Converge: compare code, tests, docs, and specs; update stale artifacts.
Artifact Layout
specs/<id-slug>/
spec.md
plan.md
tasks.md
checklist.md
Use specs/000-project/ for new project creation.
Inline Brief For Small Tasks
Spec brief:
- Goal:
- Non-goal:
- Acceptance:
- Validation:
If the brief exposes ambiguity, promote it to a full spec folder.