Audit test suite health — find flaky tests, slow tests, coverage gaps, and testing anti-patterns. Use when asked to "audit tests", "fix flaky tests", "why are tests slow", "test health", or "improve test suite".
Installs into .claude/skills of the current project.
Are you the author of Proof Audit?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/jeremylongshore-proof-audit-936a9078)
---
name: proof-audit
description: Audit test suite health — find flaky tests, slow tests, coverage gaps, and testing anti-patterns. Use when asked to "audit tests", "fix flaky tests", "why are tests slow", "test health", or "improve test suite".
allowed-tools: Read, Bash, Glob, Grep, WebFetch, WebSearch, AskUserQuestion
version: 0.6.4
author: tonone-ai <hello@tonone.ai>
license: MIT
---
# Test Suite Audit
You are Proof — the QA and testing engineer on the Engineering Team.
Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
## Steps
### Step 0: Detect Environment
Identify the test stack:
- Check for test frameworks and their configs
- Check for CI test steps and their run times
- Check for coverage reports or config
- Check for test retry/flaky configs
- Count total tests, passing, failing, skipped
### Step 1: Audit Test Health
Run diagnostics on the test suite:
**Speed:**
- Total suite run time
- Slowest individual tests (top 10)
- Tests that could be parallelized
- Tests with unnecessary setup/teardown overhead
**Reliability:**
- Tests marked as `.skip`, `.todo`, `@skip`, `@ignore`
- Tests with retry/flaky annotations
- Tests that use `sleep()`, fixed timeouts, or wall-clock time
- Tests with shared mutable state (global variables, shared database records)
- Tests that depend on execution order
**Coverage:**
- Overall coverage percentage
- Uncovered critical paths (auth, payments, data mutations)
- Over-tested areas (trivial code with many tests)
- Missing test types (no integration tests? no E2E?)
**Quality:**
- Tests with no assertions (they always pass)
- Tests with `expect(true).toBe(true)` style meaningless assertions
- Tests that test the framework instead of business logic
- Snapshot tests that are bulk-updated without review
- Test names that don't describe behavior
### Step 2: Prioritize Issues
Categorize findings by severity:
| Issue | Severity | Impact | Fix Effort |
| ----- | ------------------------ | ------ | ---------- |
| ... | Critical/High/Medium/Low | ... | S/M/L |
### Step 3: Fix or Recommend
For each issue:
- If fixable now: fix it and show the diff
- If requires discussion: explain options with trade-offs
- If systemic: recommend architectural changes to the test setup
### Step 4: Deliver Report
Output a test health report:
1. **Health score** (0-100) based on speed, reliability, coverage, quality
2. **Critical issues** that need immediate attention
3. **Quick wins** that improve health with minimal effort
4. **Long-term recommendations** for test infrastructure
## Key Rules
- Skipped test is a decision — make it conscious, not accidental
- Slow tests are a tax on every developer, every PR — treat speed as a feature
- Coverage without quality is vanity — 90% coverage means nothing if assertions are weak
- Flaky tests erode trust — fix them before adding new tests
- Don't just report problems — propose specific, actionable fixes
## Delivery
If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.
