CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/wiremock-stubs

Authors WireMock stub mappings for HTTP service mocking - `stubFor` with verb/path/header matchers + `willReturn` response shaping, lifecycle via `WireMockServer` (start / stop) or JUnit `WireMockExtension`, request verification via `verify()`, and dynamic-port allocation for parallel tests. Also carries the Mountebank multi-protocol workflow (TCP / SMTP / LDAP / gRPC imposters, record-playback proxying) in references/mountebank.md. Use when the project is JVM-based and tests need to mock HTTP dependencies (third-party APIs, internal microservices) at the network layer, or when mocking must go beyond HTTP.

72

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, executable skill body with strong progressive disclosure into real reference files and concrete validation via verify(). Minor conciseness trims and an explicit error-recovery feedback loop would lift it further.

DimensionReasoningScore

Conciseness

Largely lean and assumes Claude's competence (no explanation of what WireMock is), but a few editorial asides — e.g. 'a common cause of test passed locally, failed on CI puzzles' — could be trimmed.

4 / 5

Actionability

Copy-paste-ready executable snippets for Maven/Gradle, JUnit 4 @Rule, JUnit 5 @WireMockTest, stubFor/verify usage, and CI YAML cover the common cases, with the 3.x placeholder explicitly flagged for pinning.

5 / 5

Workflow Clarity

A clear install→author→verify→CI sequence with verify() presented as an explicit validation checkpoint that throws on mismatch; falls short of a full validate→fix→retry feedback loop checklist.

4 / 5

Progressive Disclosure

Overview body keeps quick-start content inline and offloads matcher/scenario bulk to real one-level-deep references (matchers-and-scenarios.md, mountebank.md), both clearly signaled and present in the bundle.

5 / 5

Total

18

/

20

Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, concrete description that covers capabilities comprehensively and gives explicit trigger guidance with clear boundaries against sibling skills. Only trigger-term synonym coverage leaves minor room for improvement.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — `stubFor`/verb-path-header matchers, `willReturn` response shaping, `WireMockServer` lifecycle start/stop, `WireMockExtension`, `verify()`, dynamic-port allocation — plus the Mountebank multi-protocol workflow, giving comprehensive concrete coverage.

5 / 5

Completeness

Explicitly answers what (authors stub mappings, lifecycle, verification, dynamic ports) and when ('Use when the project is JVM-based and tests need to mock HTTP dependencies ... or when mocking must go beyond HTTP') with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural user-facing phrases like 'mock HTTP dependencies', 'third-party APIs', 'internal microservices', 'network layer', and 'parallel tests' are present, but coverage of synonyms and extension/alias variants is not fully comprehensive.

4 / 5

Distinctiveness Conflict Risk

Clear JVM/WireMock niche with explicit boundaries against the msw-handlers JS/TS counterpart and Mountebank multi-protocol scope, minimizing conflict risk.

5 / 5

Total

19

/

20

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents