tdd-loop
Skill0 starsChanged 4 months agoMITView on GitHub
Enforce red-green-refactor when implementing a feature from acceptance criteria. Use whenever the user gives acceptance criteria or a spec before any code exists, asks for test-driven development explicitly, or when code-archaeology's plan phase hands off a change with machine-checkable acceptance criteria. Not for legacy code with no spec — that's characterization-tests instead.
9 other projects use a version of this.
Adopted by
Most recently taken up by
- milad-ahmd/agent-skillstheir own version, first seen Nov 8, 2026
- OrionArchitekton/orion-skillstheir own version, first seen Nov 2, 2026
- michaelalber/ai-toolkittheir own version, first seen Nov 1, 2026
- daniel-kindl/dkstacktheir own version, first seen Nov 1, 2026
- sbradl/claude-skillstheir own version, first seen Oct 15, 2026
- dagarre00/claude-code-templatetheir own version, first seen Oct 15, 2026
Other versions9 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 9
- khuynh22/agent-dev-team★ 9same name
- ramboz/jig★ 7same name
- milad-ahmd/agent-skills★ 5same name
- michaelalber/ai-toolkit★ 3same name
- OrionArchitekton/orion-skills★ 2same name
- qyndex/claude-init★ 2same name
- dagarre00/claude-code-template★ 1same name
- daniel-kindl/dkstack★ 1same name
- sbradl/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
- angular-enterpriseSkill
- angular-migrationSkill
- characterization-testsSkill
- claude-md-architectSkill
- code-archaeologySkill
- feature-flag-changeSkill
- frontend-review-checklistSkill
- rxjs-modernizeSkill
- session-hygieneSkill
- session-stateSkill
- strangler-migrationSkill
The file
We split this skill into the rules it gives an agent
9 rules. 0 are common, 9 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 9 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Run the tests. Confirm they fail, and confirm they fail for the RIGHT reason (missing implementation), not a setup/typo error.
- Distinctive: line 22
Write the minimal implementation to make the failing test(s) pass.
- Distinctive: line 25
Hard ban: do not edit the test file during this phase: If the test turns out to be wrong (bad assertion, wrong fixture), STOP, say why, and …
- Distinctive: line 29
Run tests again. Confirm green.
- Distinctive: line 32
Only after green: refactor for clarity/duplication if warranted.
- Distinctive: line 40
Never write implementation before the failing test exists.
- Distinctive: line 41
Never edit the test under test during the Green phase to force a pass.
- Distinctive: line 42
Never call a suite "green" without having actually run it this session.
- Distinctive: line 43
Never skip Phase 1 because "the change is small" — small changes are exactly where skipping the loop is cheapest to regret.
“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- owner: Muskan, added: 2026-07-16, model: claude-sonnet-5, review: quarterly -->TDD Loop (Red → Green → Refactor)
Phase 1 — Red
- Convert acceptance criteria into one or more failing tests BEFORE writing any implementation code. If criteria aren't already stated as concrete input/output pairs, derive them first and confirm with the user if ambiguous.
- Run the tests. Confirm they fail, and confirm they fail for the RIGHT reason (missing implementation), not a setup/typo error. A test that errors on a syntax mistake is not "red" in the useful sense — fix the test's own bugs first, re-run, and only proceed once it fails cleanly against absent/wrong behavior.
- Report the failing output before moving on.
Phase 2 — Green
- Write the minimal implementation to make the failing test(s) pass. Minimal means: don't implement adjacent features the criteria didn't ask for.
- Hard ban: do not edit the test file during this phase. If the test turns out to be wrong (bad assertion, wrong fixture), STOP, say why, and get explicit confirmation before touching it — editing your own test to make it pass defeats the entire point of the loop.
- Run tests again. Confirm green. Report the passing output.
Phase 3 — Refactor gate
- Only after green: refactor for clarity/duplication if warranted. Re-run the full test suite after every refactor step — it must stay green throughout. If a refactor step turns a test red, revert that step before trying another approach; don't debug forward on a red refactor.
- Report a summary: red output → green output → any refactor steps and their final green confirmation.
Anti-patterns (hard bans)
- Never write implementation before the failing test exists.
- Never edit the test under test during the Green phase to force a pass.
- Never call a suite "green" without having actually run it this session.
- Never skip Phase 1 because "the change is small" — small changes are exactly where skipping the loop is cheapest to regret.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.