Content
60%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 has a clear, well-validated workflow and good single-level reference structure, but it is noticeably padded: the same multi-module, untrusted-input, and allowlist rules are stated two to three times, and the 'When to use this skill' section duplicates the frontmatter description verbatim. Trimming the redundancy and adding a post-change validation step would lift it substantially.
Suggestions
Remove the 'When to use this skill' section entirely — it repeats the frontmatter description's trigger phrases verbatim and adds nothing Claude cannot already see in the description.
State each rule once: keep the operational bullets (untrusted-POM input, allowlisted extraction, multi-module discovery, cross-module scope) in the Constraints section only, and drop their duplicates from the 'What is covered in this Skill?' list.
Add a final verification step to the workflow, e.g., 'After applying recommendations, re-run ./mvnw validate and confirm the build still passes before reporting changes.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Noticeably verbose through duplication: the untrusted-POM/allowlist rules appear in both the 'What is covered' bullets and the Constraints list, multi-module scope is stated three times ('What is covered', Constraints, and Workflow step 3), and the 'When to use this skill' section repeats the five trigger phrases already in the frontmatter description verbatim. Several of these padded sections could be cut with no loss of guidance. | 2 / 5 |
Actionability | Concrete commands are present ('./mvnw validate' or 'mvn validate') alongside specific tooling guidance (DOM/SAX/StAX, xmllint, Maven model APIs) and an explicit allowlist of fields to extract. Minor gap: no copy-paste example of an XML query invocation, so guidance is mostly but not fully executable. | 4 / 5 |
Workflow Clarity | The 4-step workflow has a clear sequence with an explicit upfront validation checkpoint and stop condition ('Run ./mvnw validate... stop if validation fails'; 'If validation fails, do not continue'). Minor gap: no post-modification verification step (e.g., re-running validate after applying recommendations), so it sits at anchor 4 rather than 5. | 4 / 5 |
Progressive Disclosure | The bundle structure is sound: one real reference file (references/110-java-maven-best-practices.md, verified to exist), one level deep, clearly signaled in both Workflow step 2 and a dedicated 'Reference' section, and the body stays an overview. Minor gap: constraint/allowlist detail repeated inline (in 'What is covered' and Constraints) could live once in the reference, keeping the organization from fully matching the anchor-5 split. | 4 / 5 |
Total | 14 / 20 Passed |