Enforce test quality rules before code ships

This skill reviews generated or changed test code before it ships, enforcing rules after the first test-writing pass and before tests are presented, committed, or merged. It targets coding agents' common over-generation failure modes - mock-heavy unit tests that assert implementation details, near-duplicate test bodies differing by one value, and tests that re-verify the framework instead of the project's own logic - each of which looks productive in a diff but costs maintenance forever. It activates reactively whenever an agent writes, edits, generates, or refactors tests in any framework, or when a user asks to write, add, or review tests.

Before reviewing, it adapts to the project: checking the project's own agent instructions and testing docs (which win on conflict), identifying the test stack to read the matching reference (pytest, PHPUnit/Pest, or Jest/Vitest), reading an additional LLM-app-testing reference if the project calls LLM APIs or wires up observability, and mapping the project's system boundaries (network, databases, filesystem, clock/randomness, third-party SDKs, LLM APIs) from existing fixtures and helpers.

Nine rules, most-severe first. Must-fix: test behavior from the caller's perspective, asserting return values and observable side effects, never that an internal helper was called with specific arguments; mock only at real system boundaries (network, LLM APIs, databases, filesystem, clock/randomness, third-party SDKs), never internal classes or helpers to isolate a "unit"; and never mock a data model, DTO, entity, or state object - construct a real instance, since mocking state hides field-name typos and validation errors, the exact bugs worth catching (if construction is painful, that's design feedback, not a reason to mock). Should-fix: merge tests that share identical setup and differ only in input/output values into one data-driven test; delete tests that don't answer "what bug does this catch that no other test catches" - constructors setting attributes, type-system-enforced rejections, or a constant equaling its literal value are common unjustified tests; name tests for the scenario (test_<scenario>_<expected_outcome>) reading like a requirement rather than echoing the function signature; and skip testing framework guarantees (that the ORM commits, the router returns 404) in favor of testing the project's own logic on top of the framework. Sacred: tests reproducing a real production bug are always justified, referencing the incident and never deleted, exempt from the unjustified-test rule entirely. Worth noting: when database queries or persistence logic is the actual subject of a test, run it against a real test database with real migrations rather than mocking the session - though mocking the database is fine when persistence is only a side effect of the behavior under test.

Violations get reported in a fixed format:

**Rule N violation** in `tests/path/file.ext::<test_name>`
- What: <one sentence describing the violation>
- Fix: <one sentence describing what to do instead>

Use it after test code is generated, edited, or refactored, or proactively while writing if invoked beforehand - asking of every new test "what specific bug does this catch that no other test catches" before writing it. It explicitly does not run tests (use the project's test runner), does not enforce code style (that's the linter's job), does not decide what to test versus how to test it, and does not flag pre-existing violations in untouched files unless asked to audit.

Input is generated or changed test code (a diff, new file, or modified section) plus the project's testing conventions and system-boundary map. Output is a violation report grouped by file, naming the rule, location, what's wrong, and the suggested fix - or, in live mode, tests written correctly the first time.

It reads matching reference files for pytest, PHPUnit/Pest, or Jest/Vitest depending on the project's stack, plus an LLM-app-testing reference adding prompt-contract, observability, and agent-flow rules for projects calling LLM APIs.

Developers and agents shipping test code who need brittle, mock-heavy, or duplicate tests caught before they become permanent maintenance drag - while production-regression tests stay protected regardless of how trivial they might otherwise look.