Content
71%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.
A well-structured skill body with excellent progressive disclosure (one real, clearly signaled reference file) and good actionability via concrete Maven commands and named test annotations. The main weaknesses are systematic repetition of the raw-Gherkin prohibition and preconditions across four sections, plus trigger phrases duplicated from the description, and generic wording in the middle workflow steps.
Suggestions
State the PRECONDITION and NO RAW GHERKIN rules once in the Constraints section and reference them from elsewhere ('see Constraints') instead of repeating them in the intro, Preconditions, and bullet list; this would cut roughly a third of the body.
Remove the 'When to use this skill' section (or replace it with a one-line pointer) since it duplicates the trigger phrases already enumerated in the description frontmatter.
Make workflow steps 2-4 concrete for this domain — e.g., step 2 'select @acceptance-tagged scenarios from the sanitized facts and name the target *AT test class', step 3 'extend BaseAcceptanceTest per the reference patterns', step 4 'run `mvn clean verify` and report Failsafe results' — instead of generic 'identify requested outcomes' and 'execute appropriate build/tests'.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body restates the same facts several times: the NO RAW GHERKIN rule appears in the intro paragraph ('Never open, parse, summarize, or transform raw `.feature` files'), in Preconditions ('raw `.feature` files are not accepted'), and again as the **NO RAW GHERKIN** constraint; the precondition is stated three times; and the 'When to use this skill' list duplicates the trigger phrases already in the description verbatim. This fits anchor 3 ('Mostly efficient but includes some unnecessary explanation or could be tightened') — it is not level 4 because the repetition is systematic padding rather than a couple of trimmable spots, though it never drifts into explaining concepts Claude already knows, which keeps it above level 2. | 3 / 5 |
Actionability | Concrete elements are present: exact commands ('Run `./mvnw compile` or `mvn compile`', 'Run `./mvnw clean verify` or `mvn clean verify`'), specific annotations (@SpringBootTest(webEnvironment = RANDOM_PORT), @ServiceConnection, @DynamicPropertySource), a real reference path, and a one-test-per-scenario rule. However, workflow steps 2-4 are generic ('Identify requested outcomes, constraints, and the minimum safe set of changes to apply', 'Execute appropriate build/tests') and no illustrative snippet appears in the body. This matches anchor 4 ('Mostly executable guidance; concrete code or commands with minor gaps') rather than 5, which expects copy-paste-ready coverage of common cases. | 4 / 5 |
Workflow Clarity | The 4-step workflow has a clear sequence and explicit validation checkpoints: MANDATORY compile before changes, SAFETY stop on failure, VERIFY (mvn clean verify) after, and a read-the-reference-first step. It does not reach anchor 5 because the checkpoints live in the Constraints section rather than being woven into the workflow (there is no 'if validation fails, then...' recovery loop inside the steps), and steps 2-4 are loosely defined; it clearly exceeds anchor 3, where validation is merely implicit or missing. | 4 / 5 |
Progressive Disclosure | The body is a genuine overview: a coverage summary, constraints, and workflow, with all detailed examples and good/bad patterns placed in a single one-level-deep reference that exists on disk and is clearly signaled three times (BEFORE APPLYING constraint, workflow step 1, and the Reference section with a proper markdown link). This matches anchor 5 ('Clear overview with well-signaled one-level-deep references; content appropriately split; easy navigation') with no inline content that should have been externalized. | 5 / 5 |
Total | 16 / 20 Passed |