Use when you need framework-agnostic WireMock guidance — stub design, JSON or programmatic mappings, precise request matching, response bodies and faults, classpath fixtures, isolation and reset between tests, verification of calls, dynamic ports and base URLs, and avoiding flaky stubs — without choosing Spring Boot, Quarkus, or Micronaut. This should trigger for requests such as Design or review WireMock stubs (JSON mappings or Java DSL); Improve request matching, isolation, or reset strategy for HTTP mocks; Add or fix verification of outbound HTTP calls to a WireMock server; Debug flaky tests involving WireMock or unmatched request journals. Part of cursor-rules-java project
59
67%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/702-technologies-wiremock/SKILL.mdQuality
Discovery
100%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 is a strong skill description that thoroughly covers specific capabilities, includes natural trigger terms developers would use, explicitly states both what it does and when to use it, and carves out a distinct niche by excluding framework-specific concerns. The description is slightly verbose but the detail serves the purpose of disambiguation. Minor improvement could be made by tightening the prose, but overall it meets or exceeds all rubric criteria.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: stub design, JSON/programmatic mappings, request matching, response bodies and faults, classpath fixtures, isolation and reset, verification of calls, dynamic ports and base URLs, and avoiding flaky stubs. | 3 / 3 |
Completeness | Clearly answers both 'what' (framework-agnostic WireMock guidance covering stub design, mappings, matching, etc.) and 'when' with explicit trigger scenarios ('This should trigger for requests such as...' followed by four concrete use cases). The 'Use when' clause is present at the very start. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'WireMock stubs', 'JSON mappings', 'Java DSL', 'request matching', 'HTTP mocks', 'flaky tests', 'unmatched request journals', 'verification of outbound HTTP calls'. These are terms a developer would naturally use when seeking WireMock help. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — it explicitly scopes itself to WireMock specifically, excludes Spring Boot/Quarkus/Micronaut integration, and targets a clear niche of HTTP stubbing/mocking with WireMock. Very unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is well-structured as a routing/overview document with clear scope boundaries and cross-references to framework-specific skills, but it critically lacks any concrete, actionable WireMock content — no code examples, no JSON mapping snippets, no specific commands. The workflow is generic and could apply to any technology skill. The skill relies entirely on an external reference file for substance, making the SKILL.md itself insufficient as standalone guidance.
Suggestions
Add at least 2-3 concrete, executable examples directly in the SKILL.md: a JSON mapping stub, a Java DSL stub, and a verification snippet — these are the core use cases and should not require navigating to a reference file.
Make the workflow WireMock-specific with concrete steps, e.g., 'Register stubs with stubFor(get(...))' → 'Run test' → 'Check unmatched requests via WireMock.findUnmatchedRequests()' → 'Fix and re-run if unmatched.'
Add a validation/debugging checkpoint in the workflow specifically for checking the unmatched request journal, which is a key WireMock debugging technique mentioned in the 'When to use' section.
Remove or condense the 'What is covered' bullet list since it largely duplicates the 'When to use' section and the description — use that space for actual examples instead.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes a 'What is covered' bullet list that largely restates the description and 'When to use' section, adding redundancy. The scope/delegation paragraph is useful but could be tighter. The constraints section is reasonably efficient but some items (like regenerating skills) are repo-maintenance concerns rather than WireMock guidance. | 2 / 3 |
Actionability | There are no concrete code examples, no executable commands for WireMock stub creation, no JSON mapping examples, no Java DSL snippets, and no copy-paste ready guidance. The entire skill delegates to a reference file for 'detailed guidance, examples, and constraints,' leaving the SKILL.md itself almost entirely abstract. | 1 / 3 |
Workflow Clarity | The workflow has four numbered steps with a verification step at the end, but the steps are generic ('Read reference,' 'Gather scope,' 'Apply changes,' 'Run verification') and lack WireMock-specific validation checkpoints. There's no explicit feedback loop for handling validation failures or unmatched request debugging. | 2 / 3 |
Progressive Disclosure | The skill references a detailed reference file (references/702-technologies-wiremock.md) and cross-references other skills appropriately, which is good structure. However, since no bundle files were provided, we cannot verify the reference exists or contains adequate content. The SKILL.md itself is too thin — it delegates almost everything, leaving the overview without enough standalone value. | 2 / 3 |
Total | 7 / 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.
3fa5789
Table of Contents
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.