Testing and TDD Skills

Best for: TDD that produces tests worth keeping, not just green ones

The most installed testing skill in the registry treats TDD as more than a loop: it is a reference for what the loop should produce. Its central idea is the seam, the public boundary where a test observes behavior without reaching inside. Before writing any test, the agent must write down the seams under test and confirm them with you, which is how testing effort lands on critical paths instead of every imaginable edge case.

The anti-patterns section names the three ways agent-written tests go bad: implementation-coupled tests that break on refactor, tautological tests that recompute the expected value the way the code does, and horizontal slicing, writing all tests up front against imagined behavior. The prescribed alternative is vertical slices, one tracer-bullet test per cycle. Refactoring is deliberately not part of the loop; it belongs to the sibling code-review skill.

• 412K installs, the registry's top testing skill
• Seams agreed with you before any test is written
• Names the tautological and implementation-coupled traps
• Tracer-bullet vertical slices, never bulk test-first

Best for: Agents that rationalize their way out of writing tests first

The superpowers suite's TDD skill is written like a legal code because agents argue like lawyers. Its Iron Law sits in a code block in capital letters: no production code without a failing test first. Wrote code before the test? Delete it and start over, and the skill pre-empts the workarounds by name: do not keep it as reference, do not adapt it while writing tests, do not look at it.

Half the document is a rationalizations table that answers every excuse an agent (or a human) produces, from too simple to test through deleting X hours of work is wasteful, each with a one-line rebuttal. Both the red and green phases carry a mandatory verify step, because a test you never watched fail proves nothing. It slots into the same suite as writing-plans, whose plans embed this skill's cycle into every task.

• Iron Law: failing test first, no exceptions
• Code written before its test gets deleted, not adapted
• Rationalizations table rebuts eleven named excuses
• Mandatory verify-red and verify-green steps every cycle

Best for: Verifying frontend behavior in a real browser

Anthropic's official web testing skill has the agent write native Python Playwright scripts instead of driving a browser through chat. It ships a with_server.py helper that starts your dev servers, waits for their ports, runs the automation, and tears everything down, including multi-server setups like a backend plus a frontend. The instructions are emphatic that helpers are black boxes: run them with --help, never read their source into context.

For dynamic apps it prescribes reconnaissance-then-action: navigate, wait for networkidle, inspect the rendered DOM, and only then pick selectors, which addresses the most common way agent browser tests fail. It also appears on our browser automation guide; it earns both spots because the same toolkit is the testing half of that category.

• Official Anthropic skill at 113K installs
• with_server.py manages dev servers around each run
• Helper scripts stay out of context by design
• Waits for networkidle before trusting the DOM

Best for: Teams whose Playwright suite is a codebase of its own

From Currents, the test observability company, and structured like a library rather than a lecture. The SKILL.md is a routing table: writing E2E tests loads the locators and assertions references, flaky test debugging loads another set, and dozens of reference files sit behind topics from OAuth flows and clock mocking to canvas, service workers, Electron apps, and browser extensions.

Its trigger description is a spectacle in itself, enumerating roughly forty situations from fixing flaky tests to performance budgets, which is why it fires reliably across so many Playwright tasks. The same progressive-disclosure design keeps each session lean: the agent loads only the two or three reference files the current activity needs. It also features on our browser automation guide; here it earns the spot as the deepest test-authoring reference in the registry.

• Routing table sends each activity to specific references
• Covers auth, mocking, a11y, Electron, and extensions
• Trigger description enumerates about forty use cases
• From Currents, who debug flaky suites for a living

Best for: Deciding what deserves an E2E test at all

Where the Playwright reference answers how, this skill answers whether. It opens with the testing pyramid and a blunt pair of lists: E2E tests are for critical user journeys, complex interactions, and real integrations, and explicitly not for unit-level logic, API contracts, or edge cases, which are too slow at this layer. Agents left unsupervised tend to write E2E tests for everything; this is the counterweight.

The patterns cover both Playwright and Cypress: data-testid selectors over CSS classes and nth-child chains, independent tests with their own data setup and cleanup, page objects, and proper waits instead of fixed timeouts, the number one flakiness cause. A debugging section walks through headed mode, trace viewer, test.step annotations, and page.pause() for interactive inspection.

• Explicit list of what E2E should never be used for
• Covers Playwright and Cypress with shared principles
• data-testid selectors as the stability baseline
• Flakiness treated as a waits problem, not a retry problem

Best for: Accurate Vitest 5 API answers instead of Jest habits

Anthony Fu is on the Vitest core team, and his skill takes an approach nobody else on this page uses: it is generated from the Vitest repository itself by scripts he publishes, stamped with a generation date and the version it tracks, currently the Vitest 5 beta. When the framework moves, the skill regenerates, which makes it the closest thing to shipping the docs inside the agent.

The structure is a reference index across core, features, and advanced tiers: config, the test and expect APIs, mocking with vi utilities, fake timers, snapshots, coverage providers, fixtures via test.extend, concurrency, and type testing with expectTypeOf. For agents that keep writing Jest idioms into Vitest projects, an authoritative per-version reference beats a general testing skill.

• Generated from Vitest source, dated and versioned
• Maintained by a Vitest core team member
• Covers vi mocking, fixtures, sharding, and type tests
• Tracks Vitest 5 beta ahead of most written docs

Best for: Python suites that go past assert equals

The pytest companion to the E2E skill from the same collection. It sets the structure first, arrange-act-assert, a tests directory split into unit, integration, and end-to-end, and a naming convention of test, unit, scenario, expected outcome, then gets into the patterns that separate real suites from tutorials: mock side effects that fail twice and then succeed for retry logic, freezegun for freezing and moving time, and markers for slow, integration, and expected-failure tests.

The worked examples are chosen for the things agents reliably get wrong, like verifying that a permanent error is not retried while a transient one is, or testing token expiry without sleeping. Deeper material sits in a references file the agent loads on demand, the same progressive-disclosure layout as the rest of the wshobson collection.

• AAA structure and a strict test naming convention
• Retry-logic testing via mock side effect sequences
• freezegun patterns for time-dependent behavior
• Details file loads only when the summary is not enough

Best for: Driving a module to full line coverage mechanically

The narrowest skill on this page, and that is its virtue. It teaches one loop: run pytest with the annotate coverage report, open the generated cov_annotate directory, find lines prefixed with an exclamation mark, write tests that cover them, and repeat until no marked lines remain. The annotated-source format matters because it gives an agent exact uncovered lines to target instead of a percentage to feel bad about.

Worth pairing with the mutation-testing skill below as a corrective, since line coverage proves execution rather than verification. As a mechanical gap-closer on a module you are hardening, it turns a vague raise the coverage request into a terminating procedure.

• One job: find uncovered lines and cover them
• Annotated reports mark each uncovered line with a !
• Gives agents exact targets, not just a percentage
• From GitHub's official awesome-copilot collection

Best for: Answering how should we test this before writing tests

A compact planning skill from Anthropic's knowledge-work plugins that triggers on questions like how should we test this and what tests do we need. It maps strategy to component type: API endpoints get unit tests for logic plus integration and contract tests, data pipelines get idempotency and transformation checks, frontends get component, interaction, visual regression, and accessibility tests, and infrastructure gets smoke and load tests.

Just as useful is its skip list: trivial getters and setters, framework code, and one-off scripts do not deserve tests, which is exactly the busywork agents produce when told to add tests without a strategy. The output is a concrete test plan with types, targets, and example cases, plus the gaps in whatever coverage already exists.

• Strategy mapped per component type, not one-size
• Names what to skip, the antidote to test busywork
• Produces a test plan with coverage targets
• Pairs with the TDD skills that then execute the plan

Best for: Proving your green suite would actually catch a bug

From security firm Trail of Bits, this skill configures mutation testing campaigns with their mewt tool (and muton, its sibling for TON smart contracts): the tool mutates your code, and every mutant your tests fail to catch is a bug the suite would have missed. It is the strongest available answer to the doubt that hangs over agent-written tests, since a tautological test passes coverage checks but kills no mutants.

The skill's actual work is campaign engineering: scoping targets file by file, tuning timeouts, filtering mutation types, and structuring two-phase runs so a large campaign finishes in hours instead of days. Results read simply, caught means your tests work, uncaught means untested logic with an exact location. The smallest install count on this page, and the pick we would defend hardest.

• Uncaught mutants are bugs your suite would miss
• Campaign scoping and timeouts, not just run it
• mewt covers Rust, Go, Solidity, TypeScript, and JS
• The quality check tautological tests cannot pass