Spec-Driven Development Skill Evaluation (#1046)

Evaluated 2026-10-01 by reading the repository through the GitHub API; nothing was cloned, installed or run. The source was an X post by @dankornas. FredAntB/Spec-Driven-Development is live and has not moved: MIT, 154 stars, a v1.0-beta release, created 2026-05-18, last pushed 2026-05-23.

Verdict: pass, kept as reference. Everything the skill does, BoB either already enforces in code or forbids. Its spec lives in local Markdown files, which BoB's work-tracking rules rule out, and it enforces the spec only by asking the agent to follow it. One idea is worth taking without the skill: an explicit Out of scope section on each capability and requirement, filed as #3554.

How the skill enforces a spec

The skill enforces nothing in code. It has no hooks, no checkpoint code and no gate; it is prompt instructions in three parts.

1. Interview first. A hard rule: no file is written until four answers are in (purpose and users, stack, deploy target, which AI tools are used), asked one question at a time.
2. Three spec files.
   • requirements.md: "shall" statements numbered REQ-001 onward, each with an acceptance criterion, plus a required, non-empty Out of Scope section.
   • design.md: maps every requirement to a design element.
   • tasks.md: one checkbox per task, each tagged [REQ-x] and given a verify step.
3. One instruction block pasted into the instruction file of every AI tool in use (CLAUDE.md, .cursorrules, Copilot, Windsurf, Aider). It says: never implement a requirement that isn't in requirements.md, never create a file that design.md doesn't imply, never tick a task without checking its criterion, and on any divergence stop, ask, and update design.md first.

Smaller parts: a check that a spec exists before any feature is coded, a retrofit mode for existing code, a CONTEXT.md journal for resuming sessions, and suggested drift metrics that nothing measures. Its CI checks the skill's own wording and sample output files, not whether an agent stays on spec.

Compared with BoB

Concern	The skill	BoB	Note
Where the spec lives	Local requirements.md, design.md, tasks.md	GitHub issues: cap, req, task	Direct conflict: BoB forbids local spec files
Testable criteria	One criterion per "shall" statement	/requirement: at least three acceptance-criteria checkboxes, the first an end-to-end slice	BoB is stronger
Tracing tasks to requirements	[REQ-x] on each task line	Each commit names its chunk and criteria (chunk n/m: AC-0x); criteria are ticked on the issue	Equivalent
Not closing unverified work	A prompt rule	The engine refuses the transition: the docs gate (#1856), the task verification gate (#1959), the bug regression gate (#518)	BoB enforces it in code
No scope creep	"Never implement requirements not in requirements.md"	An issue-scoped run never widens (#992); found problems are filed, not fixed inline; widening scope is a project decision; a flight plan fixes scope and order and refuses a stale plan (#1667)	BoB enforces it in code
Code drifting from the spec	Stop, ask, update design.md first	Re-validation when a run crosses an area seam (#1008) sorts drift into reversible and one-way; the doc-drift gate	BoB is stronger
Breaking work down	An ordered tasks.md	/capability → /requirement, /use-case, and bob decompose with gates for duplicates and testability	BoB is stronger
Resuming a session	CONTEXT.md	The warp-drive state file, the handoff record, session-report issues	Already covered
The same rules in other AI tools	One block pasted into each tool's file	None: BoB is Claude Code only	Out of scope for BoB
Retrofitting an existing codebase	A spec marked "to verify"	/doc-bootstrap; profile inference for provisioning	Partial overlap

What BoB takes from it

• An explicit Out of scope section (#3554). Nothing in the /capability, /requirement or /use-case templates asks what a piece of work leaves out; non-goals exist only in the vision. A stated boundary gives the #1008 re-validation and reviewers something concrete to check scope creep against.

Nothing else is new to BoB. The skill's interview, aimed at a beginner on a new project and asking one question at a time, also fits badly with automation Levels 2 and 3.

Not verified

• The X post itself.
• Whether the .skill file the README links to is attached to the release, and whether its plugin install command works.
• The pass/fail counts its CI reports.