Tdd

Implement features and fix bugs test-first with a strict red-green-refactor loop. Use whenever you are about to write implementation code or fix a bug — before the production code exists.From its SKILL.md

Install

npx -y skills add vasu-devs/Forge --skill tdd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.2 KB, 935 tokens by cl100k_base, as published. Nobody here has run it

████████╗██████╗ ██████╗
╚══██╔══╝██╔══██╗██╔══██╗
   ██║   ██║  ██║██║  ██║
   ██║   ██║  ██║██║  ██║
   ██║   ██████╔╝██████╔╝
   ╚═╝   ╚═════╝ ╚═════╝

Test-Driven Development

The discipline that makes every other quality claim trustworthy. Skipping it feels faster and is the most expensive habit in software.

The Iron Law

No production code without a failing test first.

If you wrote production code this session before its test and it isn't committed yet: delete it. Not comment it out, not keep it as "reference," not glance at it while writing the test — delete it, then re-derive it test-first.

This applies to your own uncommitted work, never the repo's existing code. To put pre-existing, untested code under test, do not delete it — first write a characterization test that pins its current observable behavior (even behavior you suspect is wrong), get it green, and only then change it.

Why this is non-negotiable: tests written after code ask "what does this code do?" and tend to enshrine whatever you happened to write, bugs included. Tests written first ask "what should this do?" — the only question that catches the gap.

For a bug, the law is identical: the first RED is a test that reproduces the bug and fails for the bug's reason; GREEN is the fix. No fix before that test exists (use forge:debug to find the cause if it isn't obvious).

Watch it fail

After writing the test, run it and watch it fail before implementing. If you didn't see RED, you don't know the test actually exercises the behavior — a test that passes against no implementation is testing nothing. Confirm it fails on the assertion you intended, with the expected-vs-actual you predicted — not on an import error, typo, or fixture/collection error. A test that fails for the wrong reason hasn't been watched fail.

One slice at a time (no horizontal batching)

One failing test → the minimum implementation to make it pass → repeat. Do not write all the tests and then all the code. Bulk-writing tests verifies imagined behavior and tends to test the shape of the code rather than what it does. Tracer bullets, not layers.

Refactor only on green

Never refactor while a test is RED — you won't know whether the refactor or the unfinished feature broke it. Get to GREEN, then improve with the safety net in place. During a refactor you may not change a test assertion or add new behavior; the tests stay green and unchanged. If a test has to change, you're not refactoring — go back to RED.

Test behavior, not internals

Assert observable, external behavior. Renaming a private function, splitting a class, or reorganizing internals should not break a test. If it does, that test was coupled to structure and was wrong.

Mock only at trust boundaries — network, clock, filesystem, external services. Asserting that a mock was called N times is testing internals (forbidden) unless that call is the observable behavior. Prefer real collaborators over mocks for in-process code.

Forbidden rationalizations (and the honest rebuttal)

You'll think…	The truth
"This is too simple to test."	Simple code breaks too, and the test is then trivial to write. Write it.
"I'll add tests after."	Tests-after enshrine bugs (see Iron Law). After rarely comes.
"I already manually verified it."	Manual checks don't run in CI and don't catch regressions tomorrow.
"It's the spirit that matters, not the ritual."	The ritual is the spirit. The order (fail → pass) is what creates the guarantee.

Exit

After a coherent chunk: forge:review (quality), then forge:verify (proof) before any "done." For bugs, start from forge:debug to get a reproducing test first.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 3 of the 12 instructions most tdd skills give in 935 tokens

Counted across 594 of the 695 authors here whose files we hold, read 2026-09-06

Write minimal code to pass the testhere, and in 356 of 594, across 332 files
Write a failing test before writing production codehere, and in 240 of 594, across 221 files
Refactor code only after tests passin 184 of 594, across 169 files
Refactor code while keeping tests greenhere, and in 140 of 594, across 133 files
Verify the test fails for the expected reasonin 133 of 594, across 121 files
Run tests after each refactor stepin 108 of 594, across 102 files
Use real code instead of mocks whenever possiblein 97 of 594, across 85 files
Reproduce bugs with a failing test before fixingin 90 of 594, across 81 files
Write tests before implementing codein 88 of 594, across 70 files
Verify the test passes after writing codein 71 of 594, across 61 files
Write one test for one behaviorin 71 of 594, across 63 files
Run the full test suitein 63 of 594, across 56 files

Said here and by no other author read

Run forge:review after a coherent chunk
Run forge:verify before finishing

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.