tdg-personal/springboot-verification
"Verification loop for Spring Boot projects: build, static analysis, tests with coverage, security scans, and diff review before release or PR."
77
77%
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.
The description is strong in specificity and distinctiveness, clearly listing concrete verification actions scoped to Spring Boot projects. Its main weaknesses are the lack of an explicit 'Use when...' clause and missing some natural trigger term variations (e.g., CI, pipeline, Maven/Gradle). Adding explicit trigger guidance would elevate this from a good to an excellent description.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user wants to verify, validate, or run checks on a Spring Boot project before a pull request or release.'
Include additional natural trigger terms like 'CI', 'pipeline', 'Maven', 'Gradle', 'pull request', 'pre-merge checks', and 'quality gate' to improve keyword coverage.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: build, static analysis, tests with coverage, security scans, and diff review. These are distinct, well-defined verification steps. | 3 / 3 |
Completeness | The 'what' is well covered (verification loop with specific steps), and 'when' is partially implied by 'before release or PR', but there is no explicit 'Use when...' clause with trigger guidance, which caps this at 2 per the rubric guidelines. | 2 / 3 |
Trigger Term Quality | Includes relevant terms like 'Spring Boot', 'build', 'tests', 'coverage', 'security scans', 'PR', and 'release', but misses common user variations like 'CI', 'pipeline', 'check', 'validate', 'Maven', 'Gradle', or 'pull request' (spelled out). | 2 / 3 |
Distinctiveness Conflict Risk | The combination of 'Spring Boot' with a specific verification loop (build + static analysis + tests + coverage + 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 loop skill with clear phased workflow, executable commands for both Maven and Gradle, and a useful output template. Its main weakness is verbosity—the extensive Java test examples bloat the skill significantly and teach Spring Boot testing patterns rather than focusing on the verification pipeline itself. The core verification loop is excellent but would benefit from moving detailed test examples to a separate reference file.
Suggestions
Move the detailed Java test examples (unit, integration, MockMvc) to a separate TESTING_EXAMPLES.md file and reference it from the main skill, keeping only brief descriptions of what each test type covers.
Trim the security findings section—the grep patterns are useful but the common security findings subsection could be condensed into a single code block with inline comments.
| 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 quite verbose for a verification loop skill. These are teaching Spring Boot testing patterns that Claude already knows, and could be replaced with brief references or much shorter examples. | 2 / 3 |
Actionability | Fully executable commands for each phase (Maven and Gradle variants), complete Java test examples with proper annotations and assertions, specific grep patterns for security scanning, and a concrete output template. Everything is copy-paste ready. | 3 / 3 |
Workflow Clarity | Clear 6-phase sequential workflow with explicit stop-on-failure at Phase 1, validation checkpoints (coverage thresholds, security scan results), a diff review checklist, and a structured output template that serves as a verification gate. The continuous mode section adds a feedback loop for ongoing work. | 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 benefit from being split into a separate reference file. The skill is over 150 lines when the core verification loop could be much more compact with references to detailed testing patterns. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents