$npx -y skills add levnikolaevich/claude-code-skills --skill ln-23-test-suite-auditorAudits whether an existing test suite proves important product behavior with strong, isolated tests. Use when test confidence is uncertain; not to design or implement new tests.
| 1 | # Test Suite Auditor |
| 2 | |
| 3 | **Goal:** Audit the test portfolio as a read-only confidence system. Determine which important failures the suite can detect, which tests cannot be trusted, and where maintenance cost exceeds unique regression value. |
| 4 | |
| 5 | **Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete only when its action and required evidence are complete. `N/A`, skipped, unavailable, or delegated items remain incomplete. |
| 6 | Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend **Checklist: X/Y complete**<br>**Incomplete: None | section/item — reason; outcome impact; exact next action**; list every incomplete item. |
| 7 | |
| 8 | ## Tool Routing |
| 9 | |
| 10 | | Need | Preferred tool | Use it when | Fallback | |
| 11 | |---|---|---|---| |
| 12 | | Source and test inventory | Native file listing, search, manifests, and test configuration | Mapping domains, test types, runners, fixtures, and generated areas | Repository tree plus known test entrypoints | |
| 13 | | Test-to-code relationships | Language server or host-native code intelligence | Mapping units, callers, implementations, routes, and test targets | Naming and path search verified by direct reads | |
| 14 | | Execution and trust | Repository-defined test commands through the shell | Establishing pass/fail state, timing, order dependence, or reproducibility | Inspect CI results and configuration; mark execution unavailable | |
| 15 | | Coverage and missed behavior | Existing coverage tools and reports | Coverage data is configured and comparable to source scope | Static behavior-to-test mapping; never invent percentages | |
| 16 | | Flake and isolation evidence | Repeated, shuffled, parallel, or seed-controlled runs supported by the repository | A test is suspected of order, time, randomness, or shared-state dependence | History, CI logs, and code-path evidence | |
| 17 | | Assertion strength | Test reads, failure output, and configured mutation testing | Determining whether tests fail for meaningful behavioral defects | Counterfactual reasoning tied to specific assertions | |
| 18 | | Framework semantics | Official test-runner or framework documentation | A finding depends on lifecycle, fixtures, retries, isolation, or mocking behavior | Primary-source web research; otherwise mark `UNVERIFIED` | |
| 19 | |
| 20 | Run only safe test and diagnostic commands. Do not rewrite snapshots, update golden files, regenerate fixtures, or accept changed output during the audit. |
| 21 | |
| 22 | ## Evidence Rules |
| 23 | |
| 24 | - Coverage indicates execution, not proof. Require an assertion or observable oracle for important behavior. |
| 25 | - A slow test is not low-value when it uniquely protects a critical journey; a fast test is not high-value when it proves framework behavior. |
| 26 | - A flaky failure must be separated from an intermittently failing product dependency or genuinely nondeterministic requirement. |
| 27 | - Deletion recommendations require proof that another test covers the same behavior and failure modes with equal or better trust. |
| 28 | - Merge recommendations require demonstrated duplicate or fragmented coverage and must preserve distinct business and failure scenarios, oracle strength, and failure localization; a larger test is not inherently better. |
| 29 | - Known regression guards and the only proof of a rare critical edge case are not deletion candidates merely because a numeric value heuristic is low. |
| 30 | - A real dependency is not inherently a test defect. Judge whether its version, state, ownership, reset, availability, and failure evidence make the result reproducible. |
| 31 | - External testing guidance becomes actionable only when it explains a concrete weakness in this suite. |
| 32 | |
| 33 | ## Checklist |
| 34 | |
| 35 | ### 1. Map the Portfolio and Baseline |
| 36 | |
| 37 | - [ ] Detect test runners, configurations, commands, directories, fixtures, factories, snapshots, golden files, manual scripts, coverage, and mutation tooling. |
| 38 | - [ ] Map source domains and critical entrypoints to unit, integration, contract, end-to-end, and manual test surfaces. |
| 39 | - [ ] Read repository instructions and CI configuration to identify required suites, environment assumptions, retries, sharding, and exclusions. |
| 40 | - [ ] Run the smallest representative suites, then required test gates where feasible; record environment, duration, exit status, failures, skips, and retries. |
| 41 | - [ ] Separate generated, vendored, example, migration-history, and infrastructure fixtures from product tests before evaluating the portfolio. |
| 42 | - [ ] Keep the audit read-only and disclose any caches or test artifacts created by permitted commands. |
| 43 | |
| 44 | ### 2. Audit Product Value and Coverage |
| 45 | |
| 46 | - [ ] Identify uniquely critical local logic: money, authentication, authorization, data integrity, algorithms, domain rules, destructive operations, and irrevers |