This Statement Is False

Three weeks ago I released mini-spec: a ~93-line skill for spec-driven development. The idea was simple—add a design layer between specs and code so you can catch AI hallucinations before they become phantom features. It worked. But there was a problem: nothing enforced the workflow . Claude could skip the requirements phase. It could forget to link requirements to design artifacts. It could mark things implemented that weren’t. The traceability was only as good as the AI’s attention span. GitHub: https://github.com/zot/mini-spec It’s still the same 3-level process but now the enforcement is way better: Level 1: Specs What you want (human-written) Level 2: Design What the AI understood (requirements, CRC cards, sequences) Level 3: Code What got built The design level makes the AI’s interpretation explicit and reviewable before expensive code generation. Reviewing design documents is far cheaper than reviewing code. What’s new in 2.0 The minispec CLI tool – ...

mini-spec Spec-driven development for Claude in ~93 lines AI hallucinates features you didn't ask for. Sometimes they're great, so good you rely on them. Then you regenerate and they vanish. Mini-spec fixes this. GitHub: https://github.com/zot/mini-spec The three-level approach specs/ What you asked for (human-written) ↓ design/ What the AI understood (reviewable) ↓ src/ What got built (traceable) The middle layer is key . It shows how Claude interprets your specs: what you left out, where the ambiguities are, what you over-specified. Design docs are small and readable compared to code, so you can verify correctness before a single line is written. How it tracks drift design.md serves as the project's status memory. Each design file lists implementation files with checkboxes. When Claude changes code, it unchecks affected artifacts so it knows: A design review is needed Exactly what to look at There's also a "Gaps...