jbvc/springboot-verification
Verification loop for Spring Boot projects: build, static analysis, tests with coverage, security scans, and diff review before release or PR.
78
78%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description does well at specifying concrete actions and targeting a clear niche (Spring Boot verification pipeline). Its main weakness is the lack of an explicit 'Use when...' clause and some missing natural trigger term variations that users might employ. The 'before release or PR' phrase partially addresses when to use it but falls short of explicit trigger guidance.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to verify, validate, or check a Spring Boot project before a pull request, release, or merge.'
Include common trigger term variations such as 'CI', 'quality check', 'Maven', 'Gradle', 'pull request', 'pre-merge validation' to improve discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: build, static analysis, tests with coverage, security scans, and diff review. These are distinct, identifiable steps in a verification pipeline. | 3 / 3 |
Completeness | Clearly answers 'what' (verification loop with build, static analysis, tests, security scans, diff review) and implies 'when' with 'before release or PR', but lacks an explicit 'Use when...' clause with trigger guidance. Per rubric, missing explicit trigger guidance caps this at 2. | 2 / 3 |
Trigger Term Quality | Includes good terms like 'Spring Boot', 'build', 'tests', 'coverage', 'security scans', 'PR', and 'release', but misses common user variations like 'CI', 'check', 'validate', 'Maven', 'Gradle', 'pull request', or 'quality gate'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'Spring Boot' with a specific verification loop (build + static analysis + tests + security + diff review) creates a clear niche that is unlikely to conflict with generic testing or build skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured verification pipeline skill with excellent actionability and clear workflow sequencing across six phases. Its main weakness is verbosity: the extensive Java test examples (unit, integration, MockMvc) teach Spring Boot testing patterns rather than focusing on the verification loop itself, inflating the token cost. Moving detailed test examples to referenced files would significantly improve conciseness and progressive disclosure.
Suggestions
Move the detailed Java test examples (unit, integration, API) to a separate TESTING_EXAMPLES.md file and reference it from the main skill, keeping only brief command-line invocations inline.
Remove explanatory phrases like 'Test service logic in isolation with mocked dependencies' and 'Test against a real database instead of H2' — Claude already knows these patterns.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with clear commands and examples, but the extensive Java test examples (unit, integration, API tests) are verbose for a verification loop skill. These are teaching Spring Boot testing patterns that Claude already knows, and they bloat what should be a pipeline-focused skill. | 2 / 3 |
Actionability | Every phase provides fully executable commands for both Maven and Gradle. The Java test examples are complete and copy-paste ready, the security scan commands are specific, and the output template gives a concrete reporting format. | 3 / 3 |
Workflow Clarity | The six phases are clearly sequenced with explicit stop-on-failure gates (Phase 1: 'If build fails, stop and fix'). The verification loop includes re-run guidance in Continuous Mode, coverage thresholds, and a structured output template that serves as a validation checkpoint for the entire pipeline. | 3 / 3 |
Progressive Disclosure | The content is reasonably structured with clear phase headers, but the inline test examples (unit, integration, API) are extensive and would be better referenced as separate files. The skill is a monolithic document at ~180 lines when the test patterns could be split out. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
Reviewed
Table of Contents