/coverage-report
Generate a .NET code coverage report scoped to files changed in the current branch. Runs tests with coverage collection and produces filtered HTML reports.
$ npx -y skills add NikiforovAll/claude-code-rules --skill coverage-report --agent claude-codeHow 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.
- You can call itInvoke it directly when you want it.
- Slash command
/coverage-report
Context preview
The summary Claude sees to decide when to auto-load this skill.
Generate a .NET code coverage report scoped to files changed in the current branch. Runs tests with coverage collection and produces filtered HTML reports.
SKILL.md
coverage-report.SKILL.mdname: coverage-report
description: Generate a .NET code coverage report scoped to files changed in the current branch. Runs tests with coverage collection and produces filtered HTML reports.
allowed-tools: Bash(dotnet test:*), Bash(dotnet reportgenerator:*), Bash(git diff:*), Bash(git merge-base:*), Bash(start:*), Read, Grep, Glob
Code Coverage Report
Generate a code coverage report scoped to source files changed in the current branch compared to a base branch.
Workflow
1. Determine base branch
Detect the base branch to diff against. Use the MR/PR target branch if known, otherwise default to `main` or `master` (whichever exists). Ask the user if ambiguous.
git merge-base --fork-point main HEAD || git merge-base --fork-point master HEAD
2. Detect changed source files
git diff <base-branch> --name-only -- '*.cs'
Filter out test files (paths containing `Test`, `Tests`, `.Tests`, `.Test`). If no source files changed, stop and inform the user.
3. Identify test project(s)
Determine which test project(s) to run. Strategies (in order):
1. **User-specified**: If the user names a test project, use it 2. **Convention-based**: Look for test projects whose name matches the changed project (e.g., `MyProject` -> `MyProject.Tests`) 3. **Solution-wide**: Run all tests in the solution if scope is unclear 4. **Ask**: If ambiguous, ask the user which test project(s) to run
4. Clean previous results
rm -rf TestResults/
5. Run tests with coverage
dotnet test <test-project-or-solution> \
--collect:"XPlat Code Coverage" \
--results-directory ./TestResults/
6. Build file filters
From the changed file list (step 2), extract basenames and build a filter string:
+*FileName1.cs;+*FileName2.cs;+*FileName3.cs
7. Generate report
dotnet reportgenerator \
-reports:"TestResults/**/coverage.cobertura.xml" \
-targetdir:"TestResults/CoverageReport" \
-reporttypes:"Html;TextSummary" \
-filefilters:"<filters>"
8. Display results
1. Print `TestResults/CoverageReport/Summary.txt` to the terminal 2. Open the HTML report (platform-aware):
- Windows: `start TestResults/CoverageReport/index.html`
- macOS: `open TestResults/CoverageReport/index.html`
- Linux: `xdg-open TestResults/CoverageReport/index.html`
Tips
- For large solutions, scope to specific test projects to speed up collection
- The `-filefilters` flag accepts wildcards -- basename matching avoids path sensitivity
Read more
name: coverage-report description: Generate a .NET code coverage report scoped to files changed in the current branch. Runs tests with coverage collection and produces filtered HTML reports. allowed-tools: Bash(dotnet test:*), Bash(dotnet reportgenerator:*), Bash(git diff:*), Bash(git merge-base:*), Bash(start:*), Read, Grep, Glob
Code Coverage Report
Generate a code coverage report scoped to source files changed in the current branch compared to a base branch.
Workflow
1. Determine base branch
Detect the base branch to diff against. Use the MR/PR target branch if known, otherwise default to `main` or `master` (whichever exists). Ask the user if ambiguous.
git merge-base --fork-point main HEAD || git merge-base --fork-point master HEAD
2. Detect changed source files
git diff <base-branch> --name-only -- '*.cs'
Filter out test files (paths containing `Test`, `Tests`, `.Tests`, `.Test`). If no source files changed, stop and inform the user.
3. Identify test project(s)
Determine which test project(s) to run. Strategies (in order):
1. **User-specified**: If the user names a test project, use it 2. **Convention-based**: Look for test projects whose name matches the changed project (e.g., `MyProject` -> `MyProject.Tests`) 3. **Solution-wide**: Run all tests in the solution if scope is unclear 4. **Ask**: If ambiguous, ask the user which test project(s) to run
4. Clean previous results
rm -rf TestResults/
5. Run tests with coverage
dotnet test <test-project-or-solution> \ --collect:"XPlat Code Coverage" \ --results-directory ./TestResults/
6. Build file filters
From the changed file list (step 2), extract basenames and build a filter string:
+*FileName1.cs;+*FileName2.cs;+*FileName3.cs
7. Generate report
dotnet reportgenerator \ -reports:"TestResults/**/coverage.cobertura.xml" \ -targetdir:"TestResults/CoverageReport" \ -reporttypes:"Html;TextSummary" \ -filefilters:"<filters>"
8. Display results
1. Print `TestResults/CoverageReport/Summary.txt` to the terminal 2. Open the HTML report (platform-aware):
- Windows: `start TestResults/CoverageReport/index.html`
- macOS: `open TestResults/CoverageReport/index.html`
- Linux: `xdg-open TestResults/CoverageReport/index.html`
Tips
- For large solutions, scope to specific test projects to speed up collection
- The `-filefilters` flag accepts wildcards -- basename matching avoids path sensitivity
A collection of Claude Code recommendations and practices. Learn practical techniques to enhance your AI-assisted development workflow with Claude Code.
Other skills on claude-code-rules.
- /update-component-reference
This skill should be used when the user wants to add components (commands, agents, skills, hooks, or MCP servers) to the Component Reference section of the website.
Open skill - /version-bump
This skill automates version bumping during the release process for the Claude Code Handbook monorepo. It should be used when the user requests to bump versions, prepare a release, or increment version numbers across the repository.
Open skill - /spec-driven
Guide spec-driven development workflow (Requirements → Design → Tasks → Implementation) with approval gates between phases. Use when user wants structured feature planning or says "use spec-driven" or "follow the spec process".
Open skill - /subagent-review
Review changed code for reuse, quality, and efficiency using three parallel disposable subagents. This skill should be used when the user says "review", "simplify", "code review", or wants a one-shot code review without persistent reviewers.
Open skill - /team-review
Review changed code for reuse, quality, and efficiency using a team of persistent named reviewers. This skill should be used when the user says "team review", "review with team", or wants parallel code review with persistent team members for follow-up questions. Similar to
Open skill - /handbook-discover
This skill should be used when users want to discover, browse, or audit cc-handbook marketplace plugins. Shows all available plugins with installation status, versions, and component breakdown (skills, agents, commands, MCP/LSP servers, hooks). Trigger phrases include "discover
Open skill

