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.
git clone --depth 1 https://github.com/NikiforovAll/claude-code-rules /tmp/coverage-report && cp -r /tmp/coverage-report/plugins/handbook-dotnet/skills/coverage-report ~/.claude/skills/coverage-reportSKILL.md
# 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. ```bash git merge-base --fork-point main HEAD || git merge-base --fork-point master HEAD ``` ### 2. Detect changed source files ```bash 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 ```bash rm -rf TestResults/ ``` ### 5. Run tests with coverage ```bash 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 ```bash 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
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.
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.
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".
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.
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 /subagent-review but reviewers persist after review.
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 plugins", "list handbook plugins", "what plugins are available", "browse marketplace".
This skill should be used when investigating .NET project dependencies, understanding why packages are included, listing references, or auditing for outdated/vulnerable packages.
Run script-like CSharp programs using dotnet run file.cs. Use this skill when users want to execute CSharp code directly, write one-liner scripts via stdin, or learn about run file directives.