Tdd
A personal Claude Code skills library built around one deliberate, gated workflow: /spec → /plan → /build → /test → /review → /ship
npx -y skills add bingelp/skills --skill tddAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 0 stars0 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.
What its author says it does
Copied from the file, not written here
Red-green-refactor discipline for writing new functionality. Use whenever adding new behavior, a new function, or a new feature that can be driven by a test — not just when the user says "TDD".
SKILL.md
1.4 KB, as published. Nobody here has run it
TDD
Overview
Write the failing test before the code that makes it pass. Keeps scope honest and gives you a working definition of "done" for free.
When to Use
Any time you're about to add new behavior with a clear expected input/output — a new function, endpoint, component behavior, bug fix with a reproducible case.
Don't force it for: exploratory spikes, pure config/plumbing changes, or UI-only visual tweaks with nothing meaningful to assert on.
Process
- Red — write a test for the behavior that doesn't exist yet. Run it, confirm it fails for the expected reason (not a typo or import error).
- Green — write the minimum code to make it pass. Resist adding anything the test doesn't require.
- Refactor — clean up now that it's green, keeping the test passing. Don't skip this step just because green feels done.
- Repeat per behavior, not per file — small cycles.
Red Flags
- Writing the implementation first and backfilling a test — that's not TDD, note it explicitly if you do it out of necessity.
- A test that passes immediately without ever seeing it fail — you haven't verified it tests anything.
- Piling multiple behaviors into one red-green cycle — split them.
Gives 4 of the 12 instructions most tdd skills give
Counted across 439 of the 443 authors here whose files we hold, read 2026-08-06
- write minimal code to pass the testhere, and in 302 of 439, across 218 files
- write a failing test firsthere, and in 176 of 439, across 112 files
- refactor code only after tests passin 171 of 439, across 101 files
- watch the test fail before writing codein 142 of 439, across 93 files
- test one behavior per testin 106 of 439, across 44 files
- refactor code while keeping tests greenhere, and in 99 of 439, across 86 files
- delete code written before testsin 98 of 439, across 54 files
- run tests after each refactor stepin 85 of 439, across 54 files
- Use real code instead of mocks unless unavoidablein 64 of 439, across 21 files
- confirm the test fails for the right reasonhere, and in 64 of 439, across 60 files
- reproduce bugs with a test before fixingin 53 of 439, across 36 files
- write tests before implementationin 48 of 439, across 39 files
Said here and by no other author read
- repeat per behavior not per file
- split multiple behaviors into separate cycles
- note explicitly if backfilling a test
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.