springboot-tdd
Test-driven development for Spring Boot using JUnit 5, Mockito, MockMvc, Testcontainers, and JaCoCo. Use when adding features, fixing bugs, or refactoring.
78
73%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/springboot-tdd/SKILL.mdQuality
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 establishes a clear technology stack for Spring Boot testing but falls short on describing concrete actions the skill performs. The 'Use when' clause is present but overly broad—'adding features, fixing bugs, or refactoring' applies to almost any development skill, creating significant conflict risk. The description would benefit from more specific actions and narrower trigger conditions tied to testing scenarios.
Suggestions
Replace the generic triggers 'adding features, fixing bugs, or refactoring' with testing-specific triggers like 'Use when writing unit tests, integration tests, setting up test containers, or measuring code coverage for Spring Boot applications'.
Add concrete actions describing what the skill does, e.g., 'Writes unit and integration tests, configures mock dependencies, sets up Testcontainers for database testing, and generates JaCoCo coverage reports'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Spring Boot testing) and lists specific tools (JUnit 5, Mockito, MockMvc, Testcontainers, JaCoCo), but doesn't describe concrete actions like 'write unit tests', 'generate mock configurations', 'set up integration tests with containers', or 'measure code coverage'. | 2 / 3 |
Completeness | Explicitly answers both 'what' (test-driven development for Spring Boot with specific tools) and 'when' ('Use when adding features, fixing bugs, or refactoring'). The 'Use when...' clause is present, though the triggers are quite broad. | 3 / 3 |
Trigger Term Quality | Includes good technical keywords (JUnit 5, Mockito, MockMvc, Testcontainers, JaCoCo, Spring Boot) that users familiar with the stack would use, but the trigger terms 'adding features, fixing bugs, or refactoring' are overly generic and would match nearly any development skill. Missing natural terms like 'unit test', 'integration test', 'test coverage', 'write tests'. | 2 / 3 |
Distinctiveness Conflict Risk | The Spring Boot + testing tools combination creates a reasonably distinct niche, but the 'Use when adding features, fixing bugs, or refactoring' trigger is extremely broad and would conflict with virtually any development-related skill. A general Spring Boot development skill or a code refactoring skill could easily be triggered by the same requests. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
79%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, actionable skill with excellent concrete examples covering all major Spring Boot testing layers. Its main weakness is the lack of explicit validation checkpoints and feedback loops in the TDD workflow — the four-step process is stated but not reinforced with verification gates (e.g., 'run tests and confirm failure before implementing'). The content is well-organized but could benefit from splitting some reference material into linked files.
Suggestions
Add explicit validation checkpoints to the workflow, e.g., '1. Write test → run `mvn test` → confirm it FAILS. 2. Implement → run `mvn test` → confirm it PASSES. 3. Refactor → run `mvn test` → confirm still green. 4. Run `mvn verify` → check JaCoCo report at target/site/jacoco/index.html → confirm ≥80% coverage.'
Consider extracting the JaCoCo Maven/Gradle configuration and Testcontainers setup into separate referenced files (e.g., JACOCO_SETUP.md, TESTCONTAINERS.md) to keep the main skill focused on the TDD workflow and testing patterns.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient. It avoids explaining what JUnit, Mockito, or Spring Boot are, assumes Claude's competence, and every section delivers concrete value without padding. The brief pattern notes (e.g., 'Arrange-Act-Assert', 'Avoid partial mocks') are terse and useful. | 3 / 3 |
Actionability | Every major testing layer (unit, web, integration, persistence) has a fully executable, copy-paste-ready Java code example with proper annotations and assertions. CI commands, JaCoCo Maven config, and test data builder patterns are all concrete and specific. | 3 / 3 |
Workflow Clarity | The TDD workflow (write failing tests → implement → refactor → enforce coverage) is listed but lacks explicit validation checkpoints or feedback loops. There's no guidance on what to do when tests fail unexpectedly, how to verify coverage thresholds are met before proceeding, or a clear 'check coverage report → fix gaps → re-run' loop. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear section headers, but it's somewhat monolithic — the JaCoCo config, Testcontainers details, and test data builder patterns could be referenced as separate files. For a skill of this length (~120 lines of content), some sections could benefit from being split out with clear navigation links. | 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 | |
- Repository
- ysyecust/everything-claude-code
- Commit
79cc4e3
- Reviewed
Table of Contents
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.