Plan a team's test strategy and decide what kinds of testing a product actually needs, using Lisa Crispin and Janet Gregory's "Agile Testing" — the Agile Testing Quadrants, the whole-team approach to quality, and an explicit definition of "done." Use this skill whenever the user asks what kinds of tests they need, how to plan testing for a feature or release, where exploratory / performance / usability / acceptance / security testing fit, who owns quality on a team, what "done" should mean, how to balance manual vs. automated testing, or how to shape a test-automation strategy — even if they never mention the book or Crispin & Gregory. Also for questions like "what should our test strategy be", "do we even need exploratory testing", "what's our definition of done", or "how do we split testing work across the team". This skill is strategy/process advisory — for writing an individual unit test use khorikov-unit-testing / art-of-unit-testing. Enforces: classify testing with the four quadrants; treat quality as a
Write, organize, name, and tame unit tests in the style of Roy Osherove's "The Art of Unit Testing" — trustworthy, maintainable, readable tests built around a unit of work's entry point and exit points. Use this skill whenever the user asks you to write or scaffold unit tests, name or structure a test, choose between a value / state / interaction test, set up or avoid a mocking (isolation) framework, or clean up tests that are brittle, flaky, over-mocked, or unreadable — even if they never mention the book or Osherove. Also use it for questions like "how should I name this test", "why is this test so brittle", "is this a stub or a mock", or "how many asserts per test". Enforces: assert an exit point (observable behavior), never an internal call; never verify a stub; one concern per test with no logic in the test body; and prefer value/state tests over interaction tests.
Think like a skilled tester — investigate, explore, and report bugs that actually get fixed — in the style of Kaner, Bach & Pettichord's "Lessons Learned in Software Testing" (the context-driven school). Use this skill whenever the user asks how to think like a tester, how to do exploratory testing or write a charter, how to design a testing approach for their specific situation, what an oracle or heuristic is, how to write a bug report that gets fixed, whether a testing metric or "best practice" is meaningful, or what manual testing and automation are each good for — even if they never mention the book or its authors. Also for questions like "how should we test this", "is 100% automation realistic", "why isn't this bug getting fixed", or "what makes a good exploratory testing session". This skill is mindset/strategy advisory, not write-this-unit-test (use khorikov-unit-testing / effective-software-testing for that). Enforces: there are no best practices, only practices that fit a context; testing is investig
Systematically derive test cases — and judge how thorough a test suite is — in the style of Maurício Aniche's "Effective Software Testing." This is the "how do I come up with the right inputs" complement to behavior-focused unit testing. Use this skill whenever the user asks what test cases to write, how to cover a function or method, how to find missing edge cases, what to test at a boundary, how to test a complex boolean condition, whether a suite is thorough enough, how to use code coverage well, whether to reach for property-based testing, or how to make a class testable — even if they never mention the book or Aniche. Also for questions like "what inputs should I test here", "is 100% coverage enough", "how do I test all these combinations", or "why is this class so hard to test". Enforces: derive cases from the specification first (partitions + boundaries); use coverage as a guide to find gaps, never as a target; and design for controllability and observability.
Write and review unit tests in the style of Vladimir Khorikov's "Unit Testing Principles, Practices, and Patterns" (the classical/Detroit school). Use this skill whenever the user asks you to write, add, generate, scaffold, fix, refactor, audit, or review unit tests or a test suite — even if they never mention Khorikov or the book — and whenever you are about to write tests as part of a larger coding task. Also use it for questions like "what should I test here", "should I mock this", "why is this test brittle/flaky", "is this a good test", or "how should I structure this test". The skill enforces four rules above all: test OBSERVABLE BEHAVIOR not implementation details; maximize resistance to refactoring (no false failures); mock ONLY unmanaged out-of-process dependencies; and do NOT write tests for trivial code.
Get untested, hard-to-change ("legacy") code safely under test using Michael Feathers's "Working Effectively with Legacy Code" — find seams, pin current behavior with characterization tests, and break dependencies so tangled code becomes testable. Use this skill whenever the user inherits or works with code that has no tests, is hard to instantiate or hard to run in a test, is tightly coupled, or "can't be tested without rewriting it"; whenever they need to change scary code safely, wrap a test harness around it, or break a dependency on a database, singleton, global, static, or `new` — even if they never mention the book or Feathers. Also for questions like "how do I test this untested class", "how do I break this dependency", "how do I change this safely when there are no tests", or "where do I even start with this legacy code". Enforces: legacy code = code without tests; pin actual behavior with characterization tests before changing; break dependencies at a seam (don't rewrite blind); and prefer Sprout/Wr
Diagnose and fix messy, brittle, flaky, slow, or duplicated test suites using Gerard Meszaros's "xUnit Test Patterns" — the canonical catalogue of test smells and the patterns that remove them, and the authoritative Test Double taxonomy (Dummy, Stub, Spy, Mock, Fake). Use this skill whenever the user asks you to clean up, refactor, de-duplicate, or speed up tests; whenever tests are obscure, fragile, erratic/flaky, or full of copy-paste setup; whenever you need the precise difference between a stub, spy, mock, fake, or dummy; or whenever you're designing fixtures and setup/teardown — even if they never mention the book or Meszaros. Also for questions like "why are my tests so flaky/slow", "how do I share setup without coupling tests", "is this a stub or a mock", or "how do I stop duplicating test setup". Enforces: name the smell before fixing it; verify one condition per test; prefer a Fresh Fixture over a Shared Fixture; and use the five-name Test Double taxonomy precisely. This skill owns the repo's referen