Over the past few weeks I've written about the workflows I developed building production systems with AI: spec-driven development, manual RAG, grounding models against hallucinations, the Terraform discipline of plan-before-apply, and what happens when you skip all of that and vibe-code your way into a mess you can't undo.
Every post in this series was pointing at the same thing.
Today I'm sharing it.
Introducing speccraft: a Claude Code plugin for spec-first, test-driven AI development.
The one-line description from the README says it better than I can:
Terraform for AI-generated code. Versioned intent. Auto-injected memory. Cross-model review. Hook-enforced TDD.
Here's what it actually does, in plain terms.
Every change starts with a spec. /spec:new interviews you Socratically (why, what, acceptance criteria_ and writes a versioned spec file directly into your repository. Not a chat artifact. Not a prompt you'll lose at the end of the session. A durable, committed, reviewable document that defines exactly what is about to change before implementation begins.
The spec is the contract. Committing it to the repo makes that contract real.
The spec gets reviewed before code is written. /spec:review routes the spec to auxiliary agents (Codex, Gemini, OpenCode, or a Claude subagent running a critic persona) in parallel, and synthesizes the verdicts. Ambiguity, missing edge cases, untestable criteria: these surface at the spec stage, not after the implementation is already tangled across six files.
Implementation is test-first. Not by convention. By enforcement.
A hook intercepts every edit to a production file. If no sibling test file was edited more recently in the same session, the edit is blocked.
Not warned. Blocked.
Now, I know what you're thinking. We've all tried the "make no mistakes" prompt. We've all been let down.
Turns out it does work, you just have to enforce it with a hook, not a prompt.
Speccraft is how "write tests first" stops being advice and starts being a hard constraint. The model cannot skip the RED step and go straight to GREEN. You can override it (one-time, with a reason that gets logged) but you can't ignore it. The discipline is architectural, not aspirational.
The repo carries its own memory. A small .speccraft/index.md (guardrails, architecture decisions, conventions) is auto-injected at every session start. The model always knows the rules of this codebase. Not because you remembered to paste them in. Because the plugin handles it.
Heavy work is delegated to auxiliary agents. /spec:delegate codex "Generate table-driven tests for internal/health/handler.go": Codex or other agent runs the task, speccraft synthesizes the result. The right model for the right job, orchestrated from a single workflow.
Everything in this series (the Kubernetes Operator built in two weeks, the manual RAG sessions, the hallucination loops, the race condition the model confidently couldn't fix, the Terraform analogy, the vibe-coding mess I couldn't undo), all of it was pointing at the same underlying problem.
AI-assisted development is genuinely powerful. But left undisciplined, it amplifies ambition faster than it delivers correctness. Specs drift from implementations. Memory resets between sessions. Reviews are single-model and single-perspective. Tests get written after the fact, if at all.
Speccraft is the workflow I needed to build the things I was building and couldn't find anywhere else.
So I built it.
It's open source. MIT licensed. Currently Go-first, with Python support already in and more languages on the roadmap.
If you've been building with Claude Code and hitting the same walls, link in the comments.
👉 github.com/DCSTOLF/speccraft
What would you add to a workflow like this? What's the discipline you keep having to re-enforce manually?