"Claude wrote the code, and it looks right" is a famous last sentence. The skills on this list close the gap between looks right and is right — tests that actually run, reviews that catch real issues, verification that happens before the PR not during production incident postmortems.
Enforces the spec-then-code order. The skill instructs Claude to write failing tests first, confirm they fail for the expected reason, then implement, then confirm they pass. Simple in theory, regularly skipped in practice — especially by AI assistants that love to jump straight to implementation. 162,164 stars, verified.
When to use: any bugfix, any new feature with defined behavior, any refactor where you need to preserve existing behavior.
The single most under-applied skill in the Claude Code ecosystem. Before Claude claims a task is done, this skill requires running verification commands and pasting the output. No more "✓ Fixed!" with a broken build. Verified.
When to use: always. If you only install one skill from this list, pick this one.
Turns Claude into a reviewer for its own or other code. Works against a set of acceptance criteria and produces a review that reads like a senior engineer's, not a compliments bot.
When to use: before opening a PR. Catches issues that would otherwise bounce between you and the CI pipeline.
End-to-end browser testing without hand-writing Playwright setup. Part of the official 121,347-star skills plugin. Drives a real browser, asserts on DOM state, captures screenshots on failure.
When to use: any change to interactive UI. The difference between "unit tests pass" and "user flow works" is where most shipped bugs live.
A test-case generator. Given a function or spec, produces a balanced set of cases: happy path, edge, error, boundary. Part of the 2,606-star myclaude plugin. Less philosophical than Superpowers' TDD skill — just a useful tool for populating a test file fast.
When to use: when you need coverage for code that was written without tests, or when your own test imagination runs out at "it returns the right value."
How they fit together
The natural workflow: test-driven-development for new code, test-cases to fill in the gaps when you inherit untested code, webapp-testing for the UI layer, verification-before-completion to keep Claude honest, and requesting-code-review as the final gate before you push.
Install them as a set. They stack. The resulting workflow is slower than "just ship it," but it's measurably faster than "ship it, fix it, ship it again, apologize to the team."