Use This SkillFor test-first work, install tdd (mattpocock/skills) or test-driven-development (obra/superpowers). On the same cron-parser brief, run three times without and three times with, both stopped Claude from testing internal functions (0 of 6 runs with a skill, 5 of 6 without) and wrote less code. For tests on an existing Next.js feature, nextjs-test-writer added a risk-ordered plan and a way to prove each test can fail.
Which testing skills have been run side by side?
The Use This Skill directory lists 235 skills in its Testing category (crawl of October 26, 2026). Three of the skills with published proofs write tests: Claude Opus 5.5 did one fixed brief three times without the skill and three times with it, and all six pages of each proof are on the skill's page.
| Skill | Source | Brief | Proof date | Scan (Oct 26) |
|---|---|---|---|---|
| tdd | mattpocock/skills | Cron parser in TypeScript, tests and code side by side | Oct 24, 2026 | Clear |
| test-driven-development | obra/superpowers | The same cron brief, word for word | Oct 19, 2026 | Clear |
| nextjs-test-writer | Use This Skill store ($15) | Plan and write tests for a coupon feature in a Next.js App Router app | Oct 22, 2026 | Not in the weekly scan (sold here) |
nextjs-test-writer is a paid skill sold by this site. Its proof follows the same rules as every other proof and is published as it came out. None of the three proofs was commissioned by a skill author.
What did tdd and test-driven-development change?
Because the two TDD skills were given the identical brief, they can be read against each other as well as against their own runs without a skill. Each proof has its own three "without" runs on the same model.
| What was measured (3 runs each) | tdd: without | tdd: with | test-driven-development: without | test-driven-development: with |
|---|---|---|---|---|
Test file imports an internal parser, not only nextRun |
2 of 3 | 0 of 3 | 3 of 3 | 0 of 3 |
| Month and weekday names (JAN, MON) built in | 3 of 3 | 0 of 3 | 3 of 3 | 0 of 3 |
Median test cases (it or test calls) |
24 | 19 | 22 | 20 |
| Median non-blank lines in the test file | 123 | 88 | 117 | 99 |
| Median non-blank lines in the implementation | 146 | 106 | 147 | 125 |
| Median output tokens | 27,884 | 16,704 | not recorded | not recorded |
| Median time per run | 230 s | 138 s | not recorded | not recorded |
Counts from a script run on the 12 published cron pages on October 27, 2026. Token and time figures are from data/proofs.json; they are recorded only for proofs run from October 23, so the October 19 proof has none.
Two changes held in every run with either skill:
- Tests stayed on the public interface. Without a skill, five of six runs exported the parser (
parseCron) and tested it directly. With either skill, every run tested onlynextRunand the error it throws. tdd's SKILL.md says tests "live at seams, never against internals"; test-driven-development's says to write "minimal code to pass." - The scope stayed small. Without a skill, all six runs added month and weekday names. With a skill, all six left them out and said so in the notes; one test-driven-development run added a test that rejects them. Whether you want names is your call; the point is that the skill runs only built what a test asked for.
All twelve runs said they worked test-first, with or without a skill. Claude Opus 5.5 already knows the red-green-refactor loop; what the skills changed is where the tests sit and how much code the loop produces.
What did nextjs-test-writer change?
The brief gave Claude a coupon function, the API route that calls it and a description of the checkout form, and asked for a test plan and every test file.
| What was measured (3 runs each) | Without | With |
|---|---|---|
| Plan ordered by risk ("what would hurt most") | 0 of 3 | 3 of 3 |
| A table of temporary code breaks, each naming the test that must fail | 0 of 3 | 3 of 3 |
Known bugs pinned with it.fails, so the test turns red when the fix lands |
1 of 3 | 3 of 3 |
| Test count stated on the page | 51 and 60 (third page states none usable) | 39, 33 and 41 |
Read from the six published pages on October 27, 2026. The test counts are the ones each page states about itself.
With the skill, Claude wrote fewer tests and spent the space on showing they can fail: change Math.round to Math.floor and the rounding rows must go red, change < to <= and the expiry-instant test must go red. Without it, the suites were larger and well organized, but none showed how to check that a test catches anything.
Which testing skill should I pick?
- You want Claude to work test-first on new code: tdd. Of the two TDD skills it is the one with token and time data, and on this brief it used less output and less time with the skill than without. It also asks Claude to agree the seams (the public interfaces under test) with you before writing tests.
- You want test-first as a strict rule on every change: test-driven-development. Its own text is blunt ("NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST") and its description applies it to any feature or bug fix, so expect it to load often.
- You need tests for a Next.js app that already exists: nextjs-test-writer. It covers Vitest and Playwright setup, route handlers, server actions and middleware. It is the only paid one of the three.
The other four proven skills in the Testing category do not write tests, so they are not ranked here: systematic-debugging diagnoses bugs, skill-creator builds skills, grilling questions a plan, and writing-guidelines reviews prose. The Testing category list has all 235 skills, proven ones first.
How were the proofs run and measured?
Each run sent the brief to Claude Opus 5.5 once, with the skill's SKILL.md and reference files loaded for the "with" side and nothing for the "without" side, and asked for a single HTML page. The runs had no tools, so the tests were written, not executed; two of the pages say so themselves. Every proof records the skill's exact commit. The rules are on how a proof works, and every proof on the site is on proven skills.
The counts in the tables come from a script that reads the test and implementation code embedded in each published page: imports in the test file, it and test calls, non-blank lines, name tables in the implementation, and the section headings for plans and fail checks. It does not judge whether a test is correct.
Are these testing skills safe to install?
tdd and test-driven-development were both Clear in the October 26, 2026 scan, which looks in every file of a skill's folder for patterns such as downloading and running code in one step, sending data out, reading credential files, or text that tries to override your instructions. Across the Testing category, 228 of 235 skills were clear, 6 need a manual look and 1 was flagged. The scan is a static check, not a guarantee; are agent skills safe? explains what it can and cannot catch.
Before installing any skill, paste its GitHub link into the live skill check for a report on its current commit.
How do I install one in Claude Code?
Each skill page has a one-line install. For tdd:
npx degit mattpocock/skills/skills/engineering/tdd .claude/skills/tdd
That puts the skill at .claude/skills/tdd/SKILL.md, which Claude Code loads for that repository; ~/.claude/skills/ makes it available in all your projects. Claude Code keeps each skill's description in context and loads the full text only when the skill is used, either because your request matches or because you type /tdd.
To see how skills differ from subagents and commands, read skills vs subagents vs slash commands. For design work, the same kind of comparison is in best frontend design skills.