Guide · Testing

Agent skills for testing: distance from the code, then the runner

By SkillPicker Editorial · Published October 2, 2026 · 5 min read

A testing skill is a bet about distance. Close to the code, you want a fast check of one decision: given this input, that output. Farther out, you want evidence that several pieces agree, or that a person can actually finish a flow in the browser. Performance and security sit beside that line rather than on it. They ask how the system behaves under load, and how it fails when someone misuses it. A skill that is excellent at browser flows will not write a table-driven Go test, and a unit-test skill will cheerfully mock the bug your users hit.

The developers guide treats testing as one stage of building software. This guide is that stage, opened up. Candidates are the skills on the Testing topic. The topic has dozens of matches because "testing" and "QA" are broad queries. You need one runner, not the shelf.

Quick scan: how far from the code

Match the runner you already run

The highest-ranked skill, playwright-best-practices, is for writing and debugging Playwright tests: locators, the Page Object Model, fixtures, flake triage, authentication, and CI. Install it when the product has a browser UI and Playwright is the tool you want. Playwright's best-practices guide is the standard worth holding that skill to. Tests should see what a user sees, not a CSS class or a function name. Each test should be isolated, with its own storage and data. Locators should prefer role, text, and test id over XPath or CSS, because the DOM will change. Assertions should be the ones that wait until the condition is true. A check that looks once and moves on will fail or, worse, pass on a timing accident. The guide also says not to test third-party sites you do not control. A skill that asserts on someone else's checkout page is testing a site that can change tomorrow.

qa-testing-playwright and playwright-e2e-testing overlap that job. Read them if the first skill does not mention a problem you actually have, such as sharding in CI. Adding all three gives you three opinions about locators and no new evidence.

Unit skills are language skills. vitest, from Anthony Fu's skill set, is Vitest: a Vite-powered runner with a Jest-like API, mocks, coverage, and filters. unit-testing covers Jest, Vitest, or pytest, including arrange-act-assert and the point of a test double. golang-testing is table-driven Go tests, fuzzing, leak checks, and integration tests. It ranks second because Go testing is a strong query, not because a TypeScript repo should grow a Go skill. python-testing-patterns is pytest. vue-testing-best-practices is Vue Test Utils and Vitest, with Playwright only for the end-to-end slice. javascript-testing-patterns overlaps the Jest and Vitest ground. Pick the one whose runner is already in package.json or go.mod. A second unit framework is a second way to fail CI.

api-testing is the integration slice for HTTP: REST or GraphQL, schema checks, and auth, using Playwright's API client or Supertest. Use it when the contract is the API and a browser would only hide it. e2e-testing-patterns covers both Playwright and Cypress. Stay with the one your repository has already chosen.

What a generated test is worth

A skill can produce a test that passes and still locks in the wrong behavior. Snapshots are the common case: the first run records whatever the code did, including the bug, and every later run defends it. Mutation testing and a coverage gate, which unit-testing mentions, are stricter, and they are also easy to game if nobody reads the survivors. Ask of any generated test: what behavior, that a user or a caller cares about, would make this fail? If the answer is "the markup changed," the locator is the kind Playwright tells you not to write.

Flake triage belongs with the Playwright skills, and the fix is usually the test. A shared account, a clock, a network call to a service you do not control, or a locator that matches two buttons will pass on one machine and fail on CI. Isolation and a user-facing locator are the repairs. A retry count is a way to stop looking. Trace on failure, which Playwright recommends for CI retries rather than for every passing run, is how you look.

Performance and security skills on the wider list are not the next step after a unit test. They need a workload or a threat, and a unit skill that "adds security tests" by renaming assertions has not done either. Keep them as a separate install when that is the question. Code review is the neighboring topic for judging a change rather than executing a check. The Claude Code topic is the agent around both.

How to judge a candidate

• Distance: unit, integration, end to end, or a specialized check. The SKILL.md should say which.
• Runner: Playwright, Vitest, Jest, pytest, or go test. If it is not yours, skip it.
• What the user can see: for browser tests, role and text locators. A CSS selector of your stylesheet is a future flake.
• Isolation: no shared mutable account, no dependence on a site you do not operate.
• The assertion: it should fail when the behavior breaks, and wait for the UI when the UI is the subject.

Where to start

If the work is the rest of the lifecycle — designing the change, implementing it, reviewing it — go back to the developers guide and the Developers topic. Web development is the list when the system under test is a web application and you still need the build skills around the tests.

Before you install

Pick with confidence.These guides explain how to compare skills and choose the one that fits. Read each skill's own SKILL.md before installing it. How this works