Test Driven Development

This skill enforces strict TDD discipline: write a failing test, watch it fail, write minimal code to pass, then refactor. It's uncompromising about order. If you wrote code before the test, you delete it and start over, no exceptions. The guidance is direct about common rationalizations like "I'll test after" or "keep it as reference" and systematically refutes them. Use this when you want to follow red-green-refactor religiously, not when you want flexibility about testing approaches. The tone is deliberately forceful because TDD's value comes from the discipline, not loose adherence. If you're the type who skips tests "just this once," this will push back hard.