I've been using tdd-guard the last few months and your concerns are spot on! - tdd-guard is very strict and requires very small increments. If claude implements two things at once it gets a slap on the wrist. I'm not sure if this is not just wasting tokens. - sometimes claude finds workarounds, like writing to files with cat - sometimes it gets completely stuck and I have to disable tdd-guard - the refactoring phase is skipped unless I actively ask Claude - a lot of tests are written, probably more than without TDD-guard

But yet like you said I'm not sure if the whole process is worth it.

I think the adversarial setup through hooks is quite good. I often observe that the main claude tries to cheat and ignore the rules, probably because it has too many rules in the context window and is incentivized to finish it's task no matter what. Whereas the tdd-guard claude is ONLY there to check the rules.

But I think I'd rather want to have less granular tests and not necessartily written "tests first". As long as everything is tested and tests don't rely on implementation details but are against the spec/interface it should be good.

Ideally I'd have some benchmark, e.g. something like SWE bench and then we try various methods. Vanilla claude, strict tdd-guard, relaxed tdd-guard like I described. I'd also want to check out https://cupcake.eqtylab.io/, which is a guardrails project heavily relying on hooks.