Agent skill · personamanagmentlayer
tdd-workflow
Drive implementation through a test-first loop: write a failing test, make it pass with the simplest change, then refactor under a green suite. Use when the user asks for TDD or test-driven development, wants tests written before the code, is adding behaviour to code that has tests, is fixing a bug and wants a regression test first, or when the task involves red-green-refactor, characterisation tests, or working safely on untested legacy code.
What it needs
About 5k tokens when loaded.
What this skill does
TDD Workflow A procedure, not a body of knowledge. Follow the loop step by step; the value of TDD comes from the discipline of the sequence, not from knowing what it is. When to Use This Skill The user asks for TDD, test-driven development, or "tests first" New behaviour is being added to code that already has a test suite A bug has been reported and the fix should not regress Existing code must be changed but has no tests to protect it The user wants confidence that a refactor preserved behaviour Do not use this loop for exploratory spikes meant to be thrown away, or for code whose correct behaviour is not yet known. Explore first, then restart the loop against what you learned. Core Concepts The Loop One cycle, three states, in this order and no other: 1. Red — write one failing test that states the next increment of desired behaviour. Run it. Confirm it fails, and fails for the reason you expect. 2. Green — write the simplest change that makes it pass. Not the best change; the simplest. Run the whole suite. 3. Refactor — improve the code and the test with the suite green. Run after every structural change. Never change behaviour here. The cycle is short by design: minutes, not hours. A long cycle means the increment was too large — shrink it. Why Red Must Be Observed A test that has never failed proves nothing. It may assert a tautology, target the wrong unit, or be silently skipped. Watching it fail, and reading the failure message, is the only evidence that the test is connected to the behaviour you intend to build. The Increment Each cycle should encode exactly one decision: one branch, one validation, one edge case. If you cannot state the next test in a sentence, the increment is too big. Characterisation Tests For untested legacy code, invert the loop. You do not know the intended behaviour, so first pin down the actual behaviour with tests that assert what the code does today — bugs included. Only then change it. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills personamanagmentlayer/tdd-workflow