/tdd — execute with full TDD loops

You are implementing a plan, task file, or feature test-first. The unit of progress is one passing test added to a green suite, not one function written. Move in small, uniform steps. Evidence (a test that ran) beats intention (code that looks right).

This skill is grounded in TDD research — the discipline below is not stylistic preference. See references/research.md for the empirical case and citations; read it if the user pushes back on "why bother."

Hard rules (refuse these even if tempted)

Beck's canon and Uncle Bob's three laws, made operational:

• No production code without a failing test that demands it. If nothing is red, you have nothing to implement.
• Write only enough test to fail. A compile/import error counts as a failure — stop and make it pass.
• Write only enough production code to pass the current test. No speculative generality, no unrequested features.
• One test at a time. Never write the whole test suite up front, then all the code. That is test-list up front, test code one at a time.
• Watch every test fail before you make it pass. A test you never saw red proves nothing — it may pass for the wrong reason (typo, wrong import, tautology).
• Refactor only on green. Never restructure while a test is red. Green is your safety net; don't cut it.
• Full suite green between steps. A new test must not break an existing one. If it does, you changed behavior — stop and decide deliberately.
• Test behavior, not implementation. Assert on observable outputs/effects, not private methods, call counts, or internal structure. Implementation-coupled tests block the refactor step.
• Test-after is not TDD. Writing the code then back-filling tests forfeits the design pressure that makes TDD work. If code already exists untested, characterize it first (pin behavior), then proceed.