Content
65%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is highly actionable with complete, executable configuration and commands for the entire CRAP-analysis workflow, and the workflow order is easy to follow. It is weakened by missing validation/verification steps in the batch workflow, padded explanatory sections and duplicated tables, and a monolithic structure that inlines CI and exclusion detail instead of using reference files.
Suggestions
Add explicit validation checkpoints, e.g. verify `TestResults/**/coverage.opencover.xml` exists before running reportgenerator, and a fix-and-retry loop if test collection fails.
Trim the "Why CRAP Matters" section, the cyclomatic/NPath definitions, and merge the duplicated threshold/exclusion tables into one each.
Move the GitHub Actions and Azure Pipelines YAML and the exclusion-pattern details into reference files (e.g. references/ci-github.md), keeping SKILL.md as a lean overview with clearly signaled one-level-deep links.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Most content is operational (runsettings XML, commands, CI YAML), but there is unnecessary material: the "Why CRAP Matters" explanation bullets, definitions of cyclomatic/NPath complexity Claude already knows, and duplicated tables ("Recommended Standards" vs "Project Standards", and "What Gets Excluded" restating the runsettings comments). Not 2 because the padding is limited rather than pervasive; not 4 because several sections could be trimmed or merged. | 3 / 5 |
Actionability | Everything needed to execute is present and copy-paste ready: a complete coverage.runsettings XML, the .config/dotnet-tools.json manifest, exact `dotnet test`/`dotnet reportgenerator` commands, full GitHub Actions and Azure Pipelines YAML, and a one-liner Quick Reference covering the whole workflow. The common cases (collect, report, interpret, enforce in CI) are all covered with runnable commands. | 5 / 5 |
Workflow Clarity | The sequence (setup runsettings → install ReportGenerator → run tests → generate report → interpret hotspots → set thresholds/CI) is clear and reinforced by the Quick Reference, but validation checkpoints are missing or implicit: there is no check that coverage.opencover.xml was produced before invoking reportgenerator, no error-recovery loop, and the `rm -rf coverage/ TestResults/` cleanup and batch test runs have no verification steps. Per the guideline capping batch-operation workflows without validation, this cannot exceed 3. | 3 / 5 |
Progressive Disclosure | The single ~380-line file is well-sectioned with headers and has no nested references, but content that plausibly belongs in separate files is inlined (full CI pipeline YAML for two platforms, the exclusion-pattern details) and there are no bundled reference files to offload detail to. Not 4 because the SKILL.md is a long monolith rather than an overview pointing to deeper material. | 3 / 5 |
Total | 14 / 20 Passed |