Vibe Coverage Enforcer

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?"
• After vibe-spec-sync updates the spec — verify tests still cover requirements

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

Three Coverage Dimensions

Dimension 1: Line Coverage (by Tier)

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 |

Dimension 2: Spec-to-Test Coverage

Which spec requirements have corresponding tests?

1. Parse requirements from the spec document — each atomic requirement gets an ID
2. Scan test files for traceability markers:

• Comment markers: # req:[REQ-ID] or // req:[REQ-ID]
• Function name patterns: test_req_[REQ-ID]_*

1. Map: requirement → test function(s) or UNCOVERED
2. Report: X/N requirements covered (Y%)

Dimension 3: Spec-to-Code Coverage

Which spec requirements have corresponding implementations?

1. For each requirement, search the codebase for implementing code
2. Evidence: Note which file(s) and function(s) implement each requirement
3. Map: requirement → implementation location(s) or NOT_IMPLEMENTED
4. Report: X/N requirements implemented (Y%)

Steps

1. Run line coverage for the project:

• Go: go test -cover ./... or go test -coverprofile=coverage.out ./...
• JS/TS: npm test -- --coverage
• Python: pytest --cov

1. Classify packages/modules into tiers

1. Compare actual vs. target for each package (Dimension 1)

1. If a spec document exists, run Dimensions 2 and 3:

• Find the spec (same logic as vibe-spec-sync Step 1)
• Extract requirements with IDs
• Scan tests for traceability markers
• Map requirements to implementations

1. Report all dimensions

Output Format

Coverage Report

Dimension 1: Line Coverage

Overall: X%

| Package/Module | Tier | Actual | Target | Status | |---------------|------|--------|--------|--------| | auth/ | Critical | 92% | 90% | PASS | | handlers/ | Business | 75% | 80% | FAIL (-5%) | | utils/ | General | 68% | 70% | FAIL (-2%) |

Dimension 2: Spec-to-Test Coverage

Spec: [path/to/spec.md] Requirements Covered: X/N (Y%)

| REQ ID | Requirement | Test(s) | Status | |--------|-------------|---------|--------| | AUTH-001 | Login requires email + password | testlogincredentials | COVERED | | AUTH-002 | Lockout after 5 failed attempts | — | UNCOVERED | | CACHE-001 | Cache TTL is 24 hours | testreqCACHE001_ttl | COVERED |

Dimension 3: Spec-to-Code Coverage

Requirements Implemented: X/N (Y%)

| REQ ID | Requirement | Implementation | Status | |--------|-------------|---------------|--------| | AUTH-001 | Login requires email + password | src/auth.py:login() | IMPLEMENTED | | AUTH-002 | Lockout after 5 failed attempts | — | NOT IMPLEMENTED | | CACHE-001 | Cache TTL is 24 hours | src/cache.py:get() | IMPLEMENTED |

Summary

| Dimension | Score | Target | Status | |-----------|-------|--------|--------| | Line Coverage (Critical) | 92% | 90% | PASS | | Line Coverage (Business) | 75% | 80% | FAIL | | Line Coverage (General) | 68% | 70% | FAIL | | Spec-to-Test | 8/12 (67%) | 100% | FAIL | | Spec-to-Code | 10/12 (83%) | 100% | FAIL |

Action Required

1. handlers/ needs +5% line coverage — suggest testing: [specific untested functions]
2. AUTH-002 not implemented and not tested — implement first, then test
3. 4 requirements lack tests — run vibe-adversarial-test-generation in spec-driven mode

Suggested Tests

[Specific test skeletons for uncovered requirements, with req:[ID] markers]

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ash1794
• Source: ash1794/vibe-engineering
• License: MIT

Install and usage instructions live in the source repository linked above.