coverage

Measure a project's code coverage and report the coverage number. Use whenever coverage needs to be measured — a user asking to run the coverage report or check the current level, and also when the task itself calls for it: recording the starting coverage before development, confirming coverage didn't drop below the committed baseline after a change. Measures the whole project (unit + integration merged) or just one test group — a package/class glob or a subproject.

Quality

89%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a lean routing layer with concrete Gradle commands, a clear two-path workflow, and exemplary progressive disclosure that loads only the needed reference. The main gaps are externalized execution detail and the absence of an explicit build-failure recovery step.

Suggestions

Add a brief validation/recovery note for the case where the coverage Gradle task fails (e.g., re-run without `-x`, or check Docker availability for integration suites) to close the workflow_clarity gap.

Inline one minimal end-to-end command example (e.g. the console `jacocoTestReport` invocation) so the body is fully executable without opening a reference for the common case.

Dimension	Reasoning	Score
Conciseness	Lean and efficient: a dense table of Gradle tasks plus a short routing section, with no padding or explanation of concepts Claude already knows (Gradle, jacoco, Docker, Testcontainers are used without introduction).	5 / 5
Actionability	Provides concrete, executable commands (`jacocoTestReport -x testIntgr`, `--tests <glob>`, `:web:test`) and a specific tool call (`steroid_list_projects`), but the full execution sequence for each path is delegated to the reference files rather than given inline.	4 / 5
Workflow Clarity	Clear probe → branch (IDE vs console) → collect-report → act sequence with an explicit routing checkpoint and fallback messaging ('tell the user you used the console fallback'), though no explicit recovery step is given for a failing Gradle build.	4 / 5
Progressive Disclosure	A clear overview with well-signaled one-level-deep references (`references/ide.md`, `references/gradle.md`, `references/report.md`, all verified to exist); the probe-first instruction ensures only the needed reference is loaded, and heavy detail is appropriately split into references and scripts.	5 / 5
	Total	18 / 20 Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is specific, complete, and distinct: it states concrete actions, an explicit 'Use whenever...' trigger clause with several natural phrases, and a clear niche. Its only weakness is that trigger terms center on the single word 'coverage' with limited synonym variety.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — 'Measure a project's code coverage and report the coverage number', 'recording the starting coverage', 'confirming coverage didn't drop below the committed baseline' — plus scope to whole project or a group/subproject, giving comprehensive coverage of the skill's capabilities.	5 / 5
Completeness	Explicitly answers what ('Measure a project's code coverage and report the coverage number') and when ('Use whenever coverage needs to be measured — a user asking to run the coverage report or check the current level...') with concrete trigger phrases.	5 / 5
Trigger Term Quality	Good keyword coverage with 'code coverage', 'coverage report', 'coverage number', 'current level', and 'baseline', but the terms lean heavily on the single root word 'coverage' and a few natural synonyms (e.g. 'test coverage') are not present.	4 / 5
Distinctiveness Conflict Risk	Occupies a clear niche (code coverage measurement) with distinct triggers ('coverage report', 'baseline') that are unlikely to fire for sibling skills like run-tests, giving minimal conflict risk.	5 / 5
	Total	19 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: Amplicode/spring-skills
Path: skills/coverage/SKILL.md
Commit: bf19b3c

Reviewed: 5 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.