113-java-maven-documentation

Use when you need to create a DEVELOPER.md file for a Maven project — combining a fixed base template with dynamic sections derived from allowlisted Maven POM structure, including a Plugin Goals Reference, Maven Profiles table, and Submodules table for multi-module projects. This should trigger for requests such as Create DEVELOPER.md; Generate DEVELOPER.md; Maven project documentation; Add Maven documentation; Plugin goals reference. Part of Plinth Toolkit

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

57%

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

A well-structured, appropriately de-duplicated skill body that offloads detail to a real reference, but it lacks a concrete XML-querying mechanism and a verification step, and carries a step-count inconsistency.

Suggestions

Name the concrete XML tooling to use (e.g. a specific xpath/grep command or a bundled script) so the POM-query step is executable rather than abstract.

Add an explicit validation checkpoint to the workflow — e.g. 'Verify no inherited/super-POM plugins were included and that the base template was reproduced verbatim before writing DEVELOPER.md.'

Reconcile the step count: Constraints reference 'steps 1–5' but the Workflow lists only 4 steps — either add the missing step or fix the reference.

Dimension	Reasoning	Score
Conciseness	The body is lean and avoids explaining concepts Claude already knows, but the 'When to use this skill' list duplicates the description's triggers and the plugin-scope rule is repeated across both Constraints and Workflow step 4.	2 / 3
Actionability	It gives a specific allowlist of fields to extract and clear assembly/scope rules, but 'query ... with local XML tooling' never names the tool, and the executable template/catalog detail is deferred entirely to the reference rather than given inline.	2 / 3
Workflow Clarity	Four steps are clearly sequenced (query POMs, read reference, assemble, enforce scope), but there is no validation/verification checkpoint (e.g. confirm no inherited plugins slipped in or that the output matches the base template), and the Constraints say 'steps 1–5' while the Workflow lists only 4.	2 / 3
Progressive Disclosure	The body is an overview that points to a single one-level-deep, clearly-signaled reference (references/113-java-maven-documentation.md, linked in both the Workflow and a dedicated Reference section), and that file exists.	3 / 3
	Total	9 / 12 Passed

Description

90%

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

A specific, well-triggered description that clearly states both capability and activation conditions, with a minor voice issue. Tightening the lead to third person would lift specificity.

Suggestions

Rewrite the opening in third person (e.g., 'Creates a DEVELOPER.md file for a Maven project ...') and move the 'Use when ...' trigger to a separate clause to avoid the second-person voice penalty.

Dimension	Reasoning	Score
Specificity	It lists concrete actions ('create a DEVELOPER.md file', 'combining a fixed base template with dynamic sections ... Plugin Goals Reference, Maven Profiles table, and Submodules table'), which would be a 3, but the second-person phrasing 'Use when you need to create' triggers the rubric's -1 voice penalty.	2 / 3
Completeness	It answers both what ('create a DEVELOPER.md file ... combining a fixed base template with dynamic sections') and when ('Use when you need to create ...', 'This should trigger for requests such as ...').	3 / 3
Trigger Term Quality	It includes natural user phrasings such as 'Create DEVELOPER.md', 'Generate DEVELOPER.md', 'Maven project documentation', and 'Add Maven documentation' that a user would actually say.	3 / 3
Distinctiveness Conflict Risk	The niche is clear and specific (DEVELOPER.md for Maven projects with plugin goals/profiles/submodules tables), and the triggers are tied to that niche, making overlap with other skills unlikely.	3 / 3
	Total	11 / 12 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: jabrena/plinth
Commit: aaee915

Reviewed: 1 day 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.