What problem does it solve? Writing tests without a plan leads to shallow coverage: missing boundary cases, mock-only assertions that verify wiring instead of behavior, and no property tests for units that have real invariants. This Skill forces an explicit test matrix before any test code is written. ## Core Features & Use Cases - Seven coverage categories: success paths, boundary values, guard clauses, failure paths, state transitions, determinism, and properties/invariants. - The law question: each unit must declare its invariant (round-trip, idempotency, conservation) or explicitly state why none exists, with property-based cases required when a law exists. - Three independent axes per case: lane (unit/integration/e2e/contract), assertion level (behavior over wiring), and specification level S1-S6. - Mock pairing rule: every mocked boundary must name a paired integration test covering the real path. - Use Case: Before implementing a payment retry function, produce a matrix covering success, timeout retries, idempotency on duplicate calls, and a property test asserting the retry count never exceeds the configured maximum. ## Quick Start Ask the AI to build a test matrix for the function or module you are about to implement, covering all categories with lane and assertion strategy per case.