Sharing my claude driven development workflow, appreciate the feedback
If you've done TDD with Claude Code you've probably hit this: you ask it to write tests and the implementation, and it quietly writes tests that just describe what the code already does. Everything goes green and you've learned nothing. The tests are worthless.
I got tired of babysitting that, so I built the whole thing into custom slash commands and PreToolUse hooks. The idea is simple: the session that writes the tests is literally not allowed to look at the implementation. A hook blocks Read, Grep, and Bash from touching the domain folder while I'm on the test branch. It can't peek even if it wanted to.
Here's how a feature moves through it, one slash command per step:
- `/draft-spec` writes a frozen spec for one slice (one slice = one PR)
- `/write-tests` writes failing tests from that spec only, on a `test/<slug>-red` branch, hook-blocked from the code
- `/clear`, then `/implement-domain` picks up the red branch in a fresh session and builds until green. It's not allowed to edit the tests to make them pass.
- `/ship` runs a scope-aware pre-PR gate and opens the PR
The `/clear` between writing tests and writing code is the part that actually matters. Same-session test-and-code is exactly where the bias sneaks back in, so I force a hard context reset between them. `/build-feature` ties it all together and just tells me the next command to run based on the repo state, so I'm never guessing which step I'm on.
Been running real backend work through this for a while now and it's held up better than I expected.
What I'm genuinely curious about from this community:
- Is the "hook-block the test writer" thing clever or am I overengineering it?
- Anyone else leaning this hard on PreToolUse hooks to enforce process, not just permissions?
- Where does this fall apart as the project gets bigger?
Happy to share the hook scripts if people want them.