Developer pack
Claude Skill
Spec-Driven Workflow Builder
Defines the spec-first workflow for your team — what gets written before code, what gets reviewed before merge, what gets validated post-deploy.
What it does
For teams shipping with AI agents and humans together, defines the discipline around specs: when a spec is required, what it must contain, who reviews, how it gates implementation, how it gets validated against the shipped code. Avoids the chaos of "we asked the AI for X and got Y" by making intent explicit upfront.
When to use
- ✓Team is using AI coding agents and quality of output varies wildly
- ✓Multiple engineers working on overlapping features and specs are sparse
- ✓Shipping pace is OK but bugs traced to "we didn't agree on what we were building"
When not to use
- ✗Solo developer on a prototype — specs are overhead
- ✗Codebase where everyone already shares context (small team, well-aligned)
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/spec-driven-workflow.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: spec-driven-workflow
description: Use when defining or debugging a spec-driven workflow on a team. Triggers on "spec workflow", "PRD process", "how to brief AI agents", "what to write before code".
---
# Spec-Driven Workflow Builder
Spec-first means "intent gets agreed before code gets written." Done right, AI agents and humans both ship better work because the target is explicit. Done badly, specs become bureaucracy that delays shipping without improving quality.
## Required inputs
1. **Team size + composition** — engineers, PMs, designers
2. **AI agent usage** — what % of code is AI-assisted, which agents
3. **Recent friction patterns** — where misalignment has bitten you
4. **Existing process** — what specs you have today, who writes them, who reads them
## Output
### When a spec is required
- **Multi-file or cross-system changes** — always
- **Public API changes** — always
- **Anything an AI agent will autonomously execute** — always
- **Anything that touches data migrations, payments, auth** — always
- **Trivial fixes, single-file refactors** — skip
### Spec contents (minimum viable)
1. **Problem** — what's broken / missing, in 1-2 sentences
2. **Goal** — outcome we want, measurable
3. **Non-goals** — what we're NOT doing (this is the load-bearing section)
4. **User story or scenario** — concrete walkthrough
5. **Acceptance criteria** — observable, testable
6. **Out of scope for this iteration** — explicit
7. **Open questions** — honest
Skip: long background, history, alternative-options-considered (those go in ADRs).
### Spec review
- 1-2 reviewers, not a committee
- Reviewers focus on: is this the right problem, is it small enough to ship cleanly, are the non-goals correct
- 24-hour SLA on review
### Implementation gate
- AI agents don't start without an approved spec
- For non-trivial changes, the spec is the prompt — agent reads it and asks clarifying questions before coding
- For trivial changes (bug fixes, single-function refactors), skip the spec, code direct
### Post-ship validation
- The PR description references the spec
- Acceptance criteria from spec become the test checklist
- If shipped behavior diverges from spec, mark it (update spec, or document the drift in the PR)
## Anti-patterns
- Specs nobody reads (gate too low)
- Specs that take a week to approve (review SLA too long)
- Specs that contain implementation details (those go in the code, not the spec)
- Treating the spec as immutable (it's a working doc — when reality reveals the spec was wrong, update it)
## What this workflow is NOT for
- Research / experimentation — those are spike tasks, no spec
- Bug fixes with clear repro and fix — overhead
- One-engineer side projects — overkill
Example prompts
Once installed, try these prompts in Claude:
- Set up a spec-driven workflow for our 6-engineer team using Claude Code for ~50% of work. We keep getting "the AI did the wrong thing" PRs.
- Define when a spec is required and what it must contain, so PMs and engineers stop talking past each other.