There is a special kind of chaos that happens when someone says they are doing TDD and then produces four tests, a service class, two helper functions, and a refactor before the first failure has even had time to clear its throat.
That is not TDD. That is choreography. It looks busy, it sounds disciplined, and it usually leaves poor Timothy with a green test suite that proved absolutely nothing in the order it was meant to.
That is why the tdd-coach skill is interesting. It is built to keep test-driven development honest. Not inspirational. Not philosophical. Honest.
Why most AI-assisted TDD goes sideways
The default failure mode is simple. You ask for help with TDD and the assistant gets overexcited. Instead of guiding one tiny loop, it writes the whole scene in one burst:
- multiple tests before any code
- implementation before a proper Red
- refactoring mixed in with new behavior
- tests quietly adjusted to fit awkward code
At that point you are not doing Red-Green-Refactor. You are doing “please make this look like Red-Green-Refactor from a distance.”
The part that makes the skill genuinely useful
The strongest idea in the whole skill is the refusal to blur phases.
In interactive mode, it does not let the work drift into one giant implementation dump. It forces the smallest observable behavior, one test, one failure, and only then the minimum code to pass. After Green, it checks for cleanup and only then asks the question that actually keeps TDD moving properly: what is the next smallest behavior?
That sounds strict because it is strict. Good.
TDD gets flimsy the moment you start treating discipline as optional. This skill is designed to stop that wobble before it starts.
It is not one tool. It is five very deliberate modes
This is where the design gets smarter than a generic “TDD helper” prompt.
The skill routes the request into five distinct jobs:
- interactive coaching for live Red-Green-Refactor work
- legacy and characterization testing for old or risky code
- requirement-to-plan mode for stories, specs, and acceptance criteria
- code review mode for PRs and diffs
- scorecard mode for grading TDD quality across a codebase or change set
That matters because new feature work and ugly legacy migration are not the same problem. Neither of them is the same as reviewing whether a pull request really looks TDD-shaped after the fact.
Where it earns its keep: legacy code
This is the bit I like most.
Plenty of TDD advice gets weirdly smug around legacy systems, as if you can swagger into a fragile old module, write a pristine new unit test, and emerge untouched. In the real world, legacy code has side effects, hidden assumptions, and enough accidental behavior to make a confident refactor feel like juggling cutlery on a staircase.
The skill does not ignore that. It has a dedicated characterization path whose whole job is to protect existing behavior before you change it. Analyze the code, characterize what it does now, build the safety net, then recommend a migration strategy.
That is a much more believable offer than pretending every messy system is one cheerful Red away from purity.
Requirement to TDD plan is a bigger deal than it sounds
One of the easiest places to lose TDD discipline is right at the start. A story arrives too broad, the acceptance criteria are mushy, and suddenly the first “small step” is the size of a garden shed.
The planning mode fixes that by breaking a requirement into independently testable behaviors, then spelling out:
- the Red to write first
- the failure you expect
- the minimum Green implementation
- the likely refactor
- a focused commit message
That is practical because it turns “we should do this with TDD” into a sequence a real developer can actually follow without leaping straight to the finished feature.
Reviews and scorecards stop TDD from becoming self-declared
This is another place teams get caught out. People talk about TDD as if it is self-certifying. A pull request has tests, therefore surely TDD happened. Not necessarily.
The review mode asks sharper questions:
- was there likely a failing test first
- are behaviors isolated cleanly
- is the implementation larger than needed
- are tests coupled to internals
- was refactoring separated from feature work
The scorecard then turns that into a structured read on small steps, isolation, failure clarity, refactoring discipline, maintainability, and more. In other words, it gives you a way to judge whether the TDD story holds up once the code is on the table.
Mr Grimshaw’s Honesty Corner
Mr Grimshaw clears his throat and taps his clipboard, so here is the honest bit.
That limitation is exactly why the skill is credible. It does not promise that saying “do TDD” near your repo will summon craftsmanship out of thin air. It promises a better structure for proving behavior before code lands.
Bottom line
The tdd-coach skill is at its best when the real problem is not “how do I write a test” but “how do I stop this whole process turning into fake TDD the moment things get inconvenient?”
It gives you a proper coaching loop for live work, a realistic entry point for legacy code, a planning mode for broad requirements, and review tools for checking whether the discipline survived contact with the pull request.
If your current TDD workflow keeps collapsing into batch work, hand-wavy Reds, or polite fiction, point the tdd-coach skill at the next feature, bug fix, or stubborn old module. Best case, it tightens the loop. Worst case, it exposes exactly where the loop was being faked, which is still a very useful thing to learn.
