lmiranda
2d51df7a42
Phase 1b: Rename all ~94 commands across 12 plugins to /<noun> <action> sub-command pattern. Git-flow consolidated from 8→5 commands (commit variants absorbed into --push/--merge/--sync flags). Dispatch files, name: frontmatter, and cross-reference updates for all plugins. Phase 2: Design documents for 8 new plugins in docs/designs/. Phase 3: Scaffold 8 new plugins — saas-api-platform, saas-db-migrate, saas-react-platform, saas-test-pilot, data-seed, ops-release-manager, ops-deploy-pipeline, debug-mcp. Each with plugin.json, commands, agents, skills, README, and claude-md-integration. Marketplace grows from 12→20. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
64 lines
2.3 KiB
Markdown
64 lines
2.3 KiB
Markdown
---
|
|
description: Coverage gap detection, risk scoring, and prioritization
|
|
---
|
|
|
|
# Coverage Analysis Skill
|
|
|
|
## Overview
|
|
|
|
Systematic approach to identifying, scoring, and prioritizing test coverage gaps. Coverage data is a tool for finding untested behavior, not a target to maximize blindly.
|
|
|
|
## Coverage Types
|
|
|
|
| Type | Measures | Tool Support |
|
|
|------|----------|-------------|
|
|
| **Line** | Which lines executed | All tools |
|
|
| **Branch** | Which conditional paths taken | pytest-cov, istanbul, c8 |
|
|
| **Function** | Which functions called | istanbul, c8 |
|
|
| **Statement** | Which statements executed | istanbul |
|
|
|
|
Branch coverage is the minimum useful metric. Line coverage alone hides untested else-branches and short-circuit evaluations.
|
|
|
|
## Gap Classification
|
|
|
|
### By Code Pattern
|
|
|
|
| Pattern | Risk Level | Priority |
|
|
|---------|------------|----------|
|
|
| Exception handlers (catch/except) | HIGH | Test both the trigger and the handling |
|
|
| Auth/permission checks | CRITICAL | Must test both allowed and denied |
|
|
| Input validation branches | HIGH | Test valid, invalid, and boundary |
|
|
| Default/fallback cases | MEDIUM | Often untested but triggered in production |
|
|
| Configuration variations | MEDIUM | Test with different config values |
|
|
| Logging/metrics code | LOW | Usually not worth dedicated tests |
|
|
|
|
### By Module Criticality
|
|
|
|
Score modules 1-5 based on:
|
|
- **Data integrity** — Does it write to database/files? (+2)
|
|
- **Security boundary** — Does it handle auth/authz? (+2)
|
|
- **User-facing** — Does failure affect users directly? (+1)
|
|
- **Frequency of change** — Changed often in git log? (+1)
|
|
- **Dependency count** — Many callers depend on it? (+1)
|
|
|
|
## Prioritization Formula
|
|
|
|
```
|
|
Priority = (Module Criticality * 2) + (Gap Risk Level) - (Test Complexity)
|
|
```
|
|
|
|
Where Test Complexity:
|
|
- 1: Simple unit test, no mocks needed
|
|
- 2: Requires basic mocking
|
|
- 3: Requires complex setup (database, fixtures)
|
|
- 4: Requires infrastructure (message queue, external service)
|
|
- 5: Requires E2E or manual testing
|
|
|
|
## Reporting Guidelines
|
|
|
|
- Always show current coverage alongside target
|
|
- Group gaps by module, sorted by priority
|
|
- For each gap: file, line range, description, suggested test
|
|
- Estimate coverage improvement if top-N gaps are addressed
|
|
- Never recommend deleting code to improve coverage
|