project-test-coverage-analyzer

Measures test coverage per stack and writes a tiered coverage report.

1|Updated Jun 2, 2026
One-click install
npx skills add https://github.com/envoydev/claude-stack --skill project-test-coverage-analyzer-envoydev
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: project-test-coverage-analyzer
Source: https://github.com/envoydev/claude-stack/tree/main/stack/skills/project-test-coverage-analyzer
Command: npx skills add https://github.com/envoydev/claude-stack --skill project-test-coverage-analyzer-envoydev

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Teams often lack a trustworthy, up-to-date picture of how much of their codebase tests actually cover, and coverage numbers get guessed, recalled from stale docs, or padded by low-quality tests. This Skill runs the project's own instrumented test suites once per stack, judges the real numbers against the user's coverage requirement, and records the verdict in a durable, reconcilable document. ## Core Features & Use Cases - Stack-aware tooling detection: Detects the coverage tooling each surface already uses (coverlet for .NET, the Angular builder's coverage flag, the declared runner for plain JS/TS) and never installs or picks a runner itself. - Measured, judged, documented: Runs the instrumented suite once per surface, keeps raw machine-readable output (cobertura.xml, lcov.info, coverage-summary.json), and writes a COVERAGE.md with per-stack verdicts, per-module tables, and weak points tiered as small, substantial, or structural. - Use Case: Ask how covered a mixed .NET API plus Angular frontend workspace is; the Skill measures each surface separately, compares against your 90% bar, and hands a ranked weak-point list to the coverage-fix loop. ## Quick Start Measure the test coverage of this project against a 90% line coverage bar and write the coverage report.

Frequently Asked Questions about project-test-coverage-analyzer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I measure test coverage for a .NET and Angular project?▼

Run each surface's instrumented suite with the tooling the project already uses: coverlet via dotnet test for .NET producing cobertura XML, and the Angular builder's coverage flag producing lcov output. This Skill detects that tooling, runs each suite once, and records per-stack verdicts in a coverage document.

What is a good line coverage requirement for a project?▼

The bar belongs to the user, not the tool. This Skill offers 90% line coverage after exclusions as the house default when none is recorded, then records your answer in the coverage doc so it carries across runs and branches.

Does this coverage analyzer write the missing tests?▼

No. It is capture only: it measures, judges, and documents coverage but fixes nothing and writes no tests. Working the identified weak points is handled by the separate project-test-coverage-loop skill, which runs this capture as its analyze step.

What happens when a project has no test infrastructure?▼

A surface with no test script, runner config, or test runner is recorded as a 'no test infrastructure' verdict: coverage unmeasurable and the requirement unmet. It becomes a substantial weak point whose action names the missing harness; installing the runner is left to the fix loop.

Why are long-running E2E or replay suites excluded from coverage runs?▼

Long-running replay, soak, and E2E categories stay out of the measured run unless the user explicitly includes them, because they can consume enormous time and disk. They are recorded as excluded-by-default in the coverage document.

Can coverage numbers be trusted from an older branch?▼

No. The coverage doc carries a branch and commit stamp, and numbers from another branch are stale for HEAD. Every reported number comes from the current run's raw output, never recalled or carried forward from a stale document.