Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/skill-coverage-audit
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Trace codepaths in diffs, map against tests, auto-generate missing coverage — use before shipping PRs
📊 Stats
Stars3,869
Forks362
LanguageShell
LicenseMIT
📦 Ships with octo
</> SKILL.md
skill-coverage-audit.SKILL.md
---name: skill-coverage-audit
paths:
- "**/*.test.*"
- "**/*.spec.*"
- "**/coverage/**"
aliases:
- coverage-audit
- test-coverage
description: "Trace codepaths in diffs, map against tests, auto-generate missing coverage — use before shipping PRs"
trigger: |
AUTOMATICALLY ACTIVATE when user requests coverage analysis:
- "check test coverage" or "coverage audit"
- "what's not tested" or "find untested code"
- "generate tests for gaps"
DO NOT activate for:
- General code audits (use skill-audit)
- Code review without coverage focus (use skill-code-review)
- TDD workflow (use skill-tdd)
---# Test Coverage Audit
## Overview
Trace every codepath in a diff, map each path against existing tests, visualize coverage gaps, and auto-generate tests for uncovered paths.
**Core principle:** Trace codepaths in changed files -> Map against existing tests -> Score coverage quality -> Generate tests for gaps -> Report before/after counts.
---## Caps and Limits
These hard limits prevent runaway analysis:
- **30 code paths max** per audit. If a diff yields more than 30, prioritize by complexity and risk (error paths, security-sensitive branches, public API surfaces first).
- **20 tests generated max** per audit. Focus on highest-impact gaps first.
- **2-minute per-test exploration cap.** If understanding a single test path takes longer than 2 minutes, mark it as "needs manual review" and move on.
---
## Phase 1: Codepath Tracing
### Step 1: Identify Changed Files
Determine the diff scope. Use the most relevant source:
```bash
# PR diff
git diff --name-only main...HEAD
# Staged changes
git diff --name-only --cached
# Last commit
git diff --name-only HEAD~1..HEAD
```
Filter to source code files only (exclude configs, docs, generated files).
### Step 2: Trace Data Flow Through Every Branch
For each changed file, you MUST trace:
1. **Conditionals** -- Every `if/else`, `switch/case`, ternary, and pattern match. Each branch is a separate codepath.
2. **Error paths** -- Every `catch`, `throw`, error return, validation failure, and early return with error. WHY: Error paths are the most common source of untested bugs.
3. **Function calls** -- Every function invoked from changed code. Trace one level deep into callees to identify integration boundaries.
4. **Loop boundaries** -- Empty collection, single item, and multi-item paths through loops.
5. **Guard clauses** -- Every early return, null check, and permission gate.
For each no-test and smoke-only codepath, generate a test that:
1. **Follows project naming conventions** -- same directory structure, same file naming pattern
2. **Uses existing test helpers** -- import from the same test utilities the project already uses
3. **Tests behavior, not implementation** -- assert observable outcomes, not internal state
4. **Covers the specific gap** -- targets the exact branch or error path identified in Phase 1
5. **Includes edge cases** -- aim for full coverage on each generated test
### Step 3: Present Generated Tests
For each generated test, show:
```markdown
### Generated: test for [codepath description]
**Covers:** Codepath #N from [filename]
**Raises coverage:** from no-test to full coverage
[test code block]
```
### Step 4: Report Before/After
After generating all tests, show the coverage change:
```
BEFORE: 5/12 paths tested (42%)
AFTER: 11/12 paths tested (92%)
New tests generated: 6
Remaining gaps: 1 (manual review needed)
```
---
## Integration with Other Skills
### With flow-deliver / skill-code-review
Coverage audit runs as a complement to code review. When invoked during deliver phase:
1. Code review assesses quality and correctness
2. Coverage audit assesses test completeness
3. Both feed into the ship/no-ship decision
### With skill-tdd
If coverage audit finds gaps in new code, recommend the user adopt TDD for the next iteration. Coverage audit fixes existing gaps; TDD prevents future ones.
### With skill-verification-gate
After generating tests, use skill-verification-gate to run the test suite and confirm the new tests pass.
---
## Red Flags -- Do Not Do This
| Action | Why It Is Wrong |
|--------|-----------------|
| Count lines instead of paths | Line coverage misses branch coverage entirely |
| Generate tests without checking conventions | Tests that do not match project style will be rejected |
| Test implementation details | Brittle tests that break on refactoring |
| Skip error paths | Error paths are where most bugs live |
| Exceed the 30-path cap | Analysis becomes unfocused and slow |
| Generate more than 20 tests | Diminishing returns; focus on highest impact |
| Spend more than 2 min on one path | Mark as needs-manual-review and move on |
---
## Quick Reference
```
1. TRACE -> Identify all codepaths in the diff (max 30)
