/coverage-analysis

name: coverage-analysis
description: >
  Project-wide code coverage and CRAP (Change Risk Anti-Patterns) score
  analysis for .NET projects. Calculates CRAP scores per method and surfaces
  risk hotspots — complex code with low coverage that is dangerous to modify.
  Use to diagnose why coverage is stuck or plateaued, identify what methods
  block improvement, or get project-wide coverage analysis with risk ranking.
  USE FOR: coverage stuck, coverage plateau, can't increase coverage, what's
  blocking coverage, coverage gap, CRAP scores, risk hotspots, where to add
  tests, coverage analysis, coverage report.
  DO NOT USE FOR: targeted single-method CRAP analysis (use crap-score);
  auditing test code for coverage-touching or other anti-patterns (use
  test-anti-patterns); writing tests; running tests (use run-tests). Requires
  or produces coverage (Cobertura) and CRAP metrics.
license: MIT

Coverage Analysis

Purpose

Raw coverage percentages answer "what code was executed?" — they don't answer what you actually need to know:

• **What tests should I write next?** — ranked by risk and impact
• **Which uncovered code is risky vs. trivial?** — CRAP scores separate the two
• **Why has coverage plateaued?** — identify the files blocking further gains
• **Is this code safe to refactor?** — complex + uncovered = dangerous to change

This skill bridges that gap: from a bare .NET solution to a prioritized risk hotspot list, with no manual tool configuration required.

When to Use

Use this skill when the user mentions test coverage, coverage gaps, code risk, CRAP scores, where to add tests, why coverage plateaued, or wants to know which code is safest to refactor — even if they don't explicitly say "coverage analysis".

When Not to Use

• **Targeted single-method CRAP analysis** — use the `crap-score` skill instead
• **Writing or generating tests** — this skill identifies where tests are needed, not write them
• **General test execution** unrelated to coverage or CRAP analysis
• **Coverage reporting without CRAP context** — use `dotnet test` with coverage collection directly

Inputs

| Input | Required | Default | Description | |-------|----------|---------|-------------| | Project/solution path | No | Current directory | Path to the .NET solution or project | | Line coverage threshold | No | 80% | Minimum acceptable line coverage | | Branch coverage threshold | No | 70% | Minimum acceptable branch coverage | | CRAP threshold | No | 30 | Maximum acceptable CRAP score before flagging | | Top N hotspots | No | 10 | Number of risk hotspots to surface |

Prerequisites

• .NET SDK installed (`dotnet` on PATH)
• At least one test project referencing the production code (xUnit, NUnit, or MSTest) — only required for the from-scratch path; not needed when the user supplies an existing Cobertura XML
• **Optional, only for the from-scratch path:** internet/NuGet access for `dotnet add package coverlet.collector` (or `Microsoft.Testing.Extensions.CodeCoverage`) when a test project has no coverage provider yet. Skip when the user supplies an existing Cobertura XML.
• **Optional, only for Phase 5:** internet access for `dotnet tool install` (ReportGenerator). Core CRAP/coverage analysis works from Cobertura XML alone — ReportGenerator only adds HTML/CSV reports as an optional post-summary extra.

The skill auto-detects coverage provider state per test project and selects the least-invasive execution strategy:

• unified Microsoft CodeCoverage when all projects use it,
• unified Coverlet when no project uses Microsoft CodeCoverage,
• per-project provider execution when the solution is truly mixed.

No pre-existing runsettings files or manually installed tools required.

Workflow

> **MANDATORY: deliver the final assistant response with the CRAP/risk-hotspot summary BEFORE any optional work.** As soon as `Compute-CrapScores.ps1` and `Extract-MethodCoverage.ps1` return data, your **next** assistant response must contain the user-facing analysis (CRAP table, blocking methods, recommendations). Do not run ReportGenerator (Phase 5), do not install global tools, and do not start any heavy parallel work before that response is delivered. The user is judged on the final assistant message, not on side-effect files. > > If a phase fails, times out, or budget is running low, skip remaining optional work and immediately return a partial summary containing: (1) what was found in the Cobertura XML, (2) any CRAP/risk-hotspot data already extracted, (3) which methods are blocking coverage, and (4) failures encountered.

If the user provides a path to existing Cobertura XML (or coverage data is already present in `TestResults/`), **skip Phase 2 entirely** (no test execution) **and skip Phase 5 by default** (no ReportGenerator install or HTML report) — go directly from Phase 3 (analysis scripts) to Phase 4 (user-facing summary). Only run Phase 5 if the user explicitly asks for HTML/CSV reports. The Risk Hotspots table and CRAP scores are mandatory in every output — they are the skill's core value-add over raw coverage numbers.

The workflow runs in five phases. Phases 1–4 are required; Phase 5 (ReportGenerator HTML/CSV reports) is strictly optional and runs **after** the user-facing summary has been delivered. Do not parallelize Phase 5 with earlier phases — the heavy `dotnet tool install` for ReportGenerator can crash the session before Phase 4 completes.

Phase 1 — Setup (sequential)

Read `references/setup-discovery.md` and run the probes it contains, in order:

| Step | Emits | Why it matters | |------|-------|----------------| | 1. Locate the solution or project | `ENTRY_TYPE`, `ENTRY`, `TEST_PROJECTS`, `TEST_OUTPUT_ROOT` | Entry point for `dotnet test` and where skill outputs are written | | 2. Create the output directory | `COVERAGE_DIR` | Skill-owned `TestResults/coverage-analysis/`; never deletes user-supplied reports | | 2b. Discover or accept existing Cobertura XML | `EXISTING_COBE