Skip to content
Development
Skill

/coverage-analysis

Activation requires either supplied .NET coverage reports/percentages/line, branch, or condition metrics, or an explicit request to collect .NET coverage for analysis. USE FOR: interpreting that evidence, including Cobertura data, partial conditions, plateaus, target arithmetic,

From plugin
managedcode-dotnet-skills
481182 skills17 agents
Install
$ npx -y skills add managedcode/dotnet-skills --skill coverage-analysis --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/coverage-analysis

Context preview

The summary Claude sees to decide when to auto-load this skill.

Activation requires either supplied .NET coverage reports/percentages/line, branch, or condition metrics, or an explicit request to collect .NET coverage for analysis. USE FOR: interpreting that evidence, including Cobertura data, partial conditions, plateaus, target arithmetic,

SKILL.md

coverage-analysis.SKILL.md
name: coverage-analysis
description: >
  Activation requires either supplied .NET coverage reports/percentages/line,
  branch, or condition metrics, or an explicit request to collect .NET coverage
  for analysis. USE FOR: interpreting that evidence, including Cobertura data,
  partial conditions, plateaus, target arithmetic,
  project-wide coverage-backed CRAP, and coverage-backed refactoring safety.
  Analyze supplied reports directly without rerunning tests or installing
  tools. DO NOT USE FOR: requests with neither coverage evidence nor explicit
  coverage-collection intent, including hypothetical change-survival questions
  (use test-gap-analysis); CRAP or refactoring safety for one named target (use
  crap-score); or requests owned by test-tagging, find-untested-sources,
  test-anti-patterns, run-tests, or code-testing-agent.
license: MIT

Coverage Analysis

Purpose

Explain what .NET coverage evidence proves, reconcile target arithmetic, and identify the code blocking progress. Add complexity/CRAP ranking only when the user explicitly asks for risk hotspots, CRAP, priorities by risk, or refactoring safety.

When to Use

Use this skill for interpreting supplied .NET line/branch/condition evidence, coverage gaps and plateaus, target arithmetic, or explicit project-wide coverage-backed risk analysis.

When Not to Use

  • **Named method, class, or file CRAP/refactoring-safety analysis** — use the `crap-score` skill instead
  • **Static source-to-test pairing or listing files with no tests** — use `find-untested-sources`
  • **Behavioral or pseudo-mutation gaps in existing tests** — use `test-gap-analysis`
  • **Test trait/category distributions or coverage shape by test type** — use `test-tagging`
  • **Writing or generating tests** — this skill identifies where tests are needed, not write them
  • **General test execution** unrelated to coverage or CRAP analysis
  • **Only collecting .NET coverage or printing a raw percentage with no diagnosis** — use `run-tests`; use native tooling for non-.NET coverage collection or analysis. Interpreting .NET line/branch gaps remains in scope here

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 | | Existing Cobertura path | No | Discover only if not supplied | Preferred input; never rerun tests when usable | | CRAP threshold | No | 30 | Used only for explicit risk/CRAP requests | | Hotspot count | No | 3 | Explicit risk requests only; cap at 10 unless the user asks for more |

Discover optional inputs from the workspace. Do not ask for a project path when the current directory or a supplied report is sufficient.

Choose the smallest matching path

| User intent | Required work | Do not do | |-------------|---------------|-----------| | Explain a supplied excerpt, condition, or summary | Answer directly from the supplied evidence | Tools, CRAP, discovery, report files | | Interpret a supplied Cobertura path or diagnose a plateau | Read that report, reconcile totals, name all material gaps, answer directly | Rerun tests, install tools, compute CRAP, or generate files unless explicitly requested | | Rank risk hotspots, compute project-wide CRAP, or assess refactoring safety | Use the supplied/existing report, read `references/guidelines.md`, and compute CRAP before ranking | Coverage-only ranking or a full report template unless requested | | Analyze coverage when no report exists | Invoke `run-tests` to collect coverage with the repository-compatible runner, then analyze the generated report | Choose or execute a test command independently; CRAP unless risk was requested | | Produce a full markdown/HTML/CSV report | First deliver the direct answer; then read `references/output-format.md` or `references/report-generation.md` | Report generation before the answer |

Words such as **analyze coverage**, **what is blocking coverage**, or **why is coverage stuck** do not by themselves request CRAP. Explicit signals include **risk hotspot**, **CRAP**, **complexity-weighted priority**, **safe to refactor**, or an equivalent request to combine complexity with coverage.

Existing-data fast path

When the user supplies a coverage excerpt, summary, or valid Cobertura path:

  • Treat it as authoritative input and start there.
  • Do not discover the solution or test projects unless source mapping is necessary.
  • Do not run `dotnet test`, install ReportGenerator, add a coverage package, or

read `references/setup-discovery.md` or `references/report-generation.md`.

  • Do not write `coverage-analysis.md` or create a report directory unless the user

requested a saved/full report.

  • For interpretation and plateau questions, parse only the evidence needed to

answer. For explicit project-wide risk requests, use the bundled scripts as described in `references/guidelines.md`.

A failed read/view operation is not proof that a named path does not exist. Classify the failure, then make one targeted existence probe and use a normalized path or alternate reader only for confirmed tool availability, transport, or path-normalization failures and only after verifying the canonical path remains inside the workspace. Stop on content-exclusion, permission/policy, workspace-boundary, or unknown failures. Report a missing path only when the independent probe also fails; do not broaden the search or substitute another artifact.

Collection path

Use this path only when no usable coverage evidence exists and the user asked for analysis that requires it.

1. Read `references/setup-discovery.md`. 2. Prefer existing Cobertura discovered under the requested root. 3. If none exists, invoke `run-tests` for repository overlay, platform, runner, and command selection, and have it coll

Read more
Ships withmanagedcode-dotnet-skills

Stop explaining .NET to your AI. Start building. We've all been there: asking Claude to use Entity Framework, only to get EF6 patterns in a .NET 8 project. Explaining to Copilot that Blazor Server and Blazor WebAssembly aren't the same thing.

Get the whole plugin

Other skills on managedcode-dotnet-skills.