testing-firstlisted

Enforces test-first implementation — the Iron Law (no production code without a failing test first), RED-GREEN-REFACTOR with both verification beats mandatory, and the rationalization table that catches "just this once". Cycle evidence lands in the lane's PROGRESS.md, and completion hands off to work-verify instead of being self-claimed. Use before writing implementation code for any feature, bugfix, or behavior change; when writing or reviewing a test; when tests are being added after the fact; when authoring a skill or an eval, where the eval is the failing test; and whenever time pressure, sunk cost, or "I already manually tested it" is arguing for skipping TDD. Covers test-driven development (TDD).
bygama/skills · ★ 0 · Testing & QA · score 70

Install: claude install-skill bygama/skills

# Testing first  Write the test first. Watch it fail. Write the least code that passes. **If you did not watch the test fail, you do not know it tests the right thing.** That single sentence is the whole discipline; everything below defends it against the arguments you will make against it. Violating the letter of the rules is violating the spirit of the rules. ## The Iron Law ``` NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST ``` Wrote the code before the test? Delete it and start from the test. Delete means delete. Not kept as reference, not "adapted" while the tests get written, not read one more time. Code you keep is code you reproduce — and reproducing it is testing after, with extra steps. **Applies to:** new features, bugfixes, refactors, behavior changes. **Applies here too:** a skill, an eval, a prompt, a script. In this library the failing test is the eval, which is why evals change before content does — same law, different artifact. **Exceptions:** throwaway prototypes, generated code, configuration. These are the owner's call, not yours to grant — route the ask through the la