Tdd
Personal AI agent skills for better coding. Fixes common agent failure modes: misaligned requirements, blind coding, debugging loops, and lost context between sessions.
npx -y skills add tyecode/skills --skill tddAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 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
Enforces test-driven development — failing test written before any implementation code. Use when adding features, fixing bugs, writing tests, or when user says "use TDD".
SKILL.md
2.2 KB, as published. Nobody here has run it
Skill: tdd
When to Use This Skill
Use this skill when:
- User wants to add a feature or fix a bug
- User says "write tests" or "use TDD"
- User wants test coverage for existing code
The Rule
Write a failing test before writing any implementation code.
If you cannot write the test first, stop and explain why before proceeding.
The Loop
- Red — Write the smallest failing test that defines the desired behavior. Run it. Confirm it fails for the right reason — not a compile error, not a missing import.
- Green — Write the minimum code to make it pass. No more.
- Refactor — Clean up. Tests must still pass after every change.
Each cycle should take minutes, not hours. If a cycle is taking too long, the unit is too large — break it down.
What to Test
- Test behavior, not implementation. Test what the code does, not how it does it.
- If you're testing a private method, the design is wrong — extract it into its own unit.
- One assertion per test when possible. Multiple assertions hide which one failed.
Test Names
Write test names as sentences that describe behavior:
it('returns null when user is not found')notit('test getUserById')it('throws when input is empty')notit('empty input test')
When TDD Feels Impossible
If writing the test first feels impossible, it usually signals a design problem:
- Unit is too large — break it down
- Code has hidden side effects — isolate them with dependency injection
- Wrong layer — move the test up (integration) or down (unit)
Never skip the failing test step. A test written after the code has never been seen to fail — you cannot trust it actually tests anything.
Frameworks
| Stack | Runner | Notes |
|---|---|---|
| Node/TS | Vitest (prefer) or Jest | Vitest is faster, ESM-native |
| React | Vitest + Testing Library | Test user behavior, not DOM structure |
| Python | pytest | Use fixtures for setup |
| Go | testing (built-in) | Table-driven tests for multiple cases |
Gives 5 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 passhere, and in 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 greenin 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 implementationhere, and in 48 of 439, across 39 files
Said here and by no other author read
- Break down the unit if a cycle takes too long
- Extract tested private methods into their own unit
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.