vibe-coverage-enforcer
npx machina-cli add skill ash1794/vibe-engineering/coverage-enforcer --openclawFiles (1)
SKILL.md
2.1 KB
vibe-coverage-enforcer
Coverage numbers don't guarantee quality, but low coverage guarantees surprise.
When to Use This Skill
- Before claiming a feature is complete
- After writing tests, to verify coverage meets standards
- During periodic coverage health checks
- When deciding "do I need more tests?"
When NOT to Use This Skill
- Prototype/spike code that will be rewritten
- Generated code (API clients, schema types)
- Configuration files
- When the user explicitly says coverage isn't a priority for this task
Tiered Standards
Not all code needs the same coverage:
| Tier | Target | What's Included |
|---|---|---|
| Critical | >=90% | Security, authentication, authorization, payment/billing, data integrity, encryption |
| Business | >=80% | Core business logic, API handlers, state management, validation |
| General | >=70% | Utilities, formatting, UI components, logging |
| Exempt | N/A | Generated code, test helpers, one-time scripts |
Steps
-
Run coverage for the project:
- Go:
go test -cover ./...orgo test -coverprofile=coverage.out ./... - JS/TS:
npm test -- --coverage - Python:
pytest --cov
- Go:
-
Classify packages/modules into tiers
-
Compare actual vs. target for each package
-
Report gaps:
Output Format
Coverage Report
Overall: X% (target: varies by tier)
| Package/Module | Tier | Actual | Target | Status |
|---|---|---|---|---|
| auth/ | Critical | 92% | 90% | ✓ |
| handlers/ | Business | 75% | 80% | ✗ (-5%) |
| utils/ | General | 68% | 70% | ✗ (-2%) |
Action Required
handlers/needs +5% coverage — suggest testing: [specific untested functions]utils/needs +2% coverage — suggest testing: [specific untested functions]
Suggested Tests
[Specific test skeletons for uncovered code]
Source
git clone https://github.com/ash1794/vibe-engineering/blob/master/skills/coverage-enforcer/SKILL.mdView on GitHub Overview
The vibe-coverage-enforcer ensures code meets tiered coverage targets: Critical >=90%, Business >=80%, General >=70%. It helps teams avoid releasing with hidden issues by requiring measurable coverage before considering work complete.
How This Skill Works
It reads coverage reports, maps packages to tiers, and compares actual vs. target coverage. When gaps exist, it surfaces them for remediation and records suggested tests to close the gaps.
When to Use It
- Before claiming a feature is complete
- After writing tests, to verify coverage meets standards
- During periodic coverage health checks
- When deciding 'do I need more tests?'
- For ongoing risk-based auditing of critical paths
Quick Start
- Step 1: Run coverage for the project: Go: go test -cover ./...; JS/TS: npm test -- --coverage; Python: pytest --cov
- Step 2: Classify packages into Critical, Business, General, and Exempt tiers
- Step 3: Review the report, address gaps with targeted tests, and re-run to confirm
Best Practices
- Prioritize Critical tier coverage first for security, data integrity, and auth paths
- Exclude Exempt tier (generated code, test helpers, one-time scripts) from targets
- Document gaps with suggested tests and the intended coverage uplift
- Automate tier classification and comparison in CI to catch drift early
- Reclassify packages as code evolves and features change to keep targets relevant
Example Use Cases
- auth/ achieves Critical coverage at or above 92%, validating security and access controls
- handlers/ falls short on Business target (e.g., 75%) and prompts API handler tests
- utils/ sits near General target (around 68-70%), triggering minor utility/test enhancements
- coverage job runs in CI and flags gaps with suggested test additions
- generated clients and schema files are marked Exempt and excluded from targets
Frequently Asked Questions
Add this skill to your agents
