CtrlK
BlogDocsLog inGet started
Tessl Logo

702-technologies-wiremock

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 Plinth Toolkit

64

Quality

75%

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

Fix and improve this skill with Tessl

tessl review fix ./skills/702-technologies-wiremock/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

56%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 clean, well-organized overview that excels at progressive disclosure and workflow sequencing, but the body itself is light on executable WireMock guidance — concrete examples live only in the reference — and carries some generic, duplicative process text.

Suggestions

Add one or two short, concrete WireMock examples inline (a JSON mapping stub and a Java DSL stub with request matching) so the body is actionable without forcing a jump to the reference.

Tighten or remove the 'When to use this skill' section, which repeats the description's trigger phrases verbatim, and replace generic Workflow step text with WireMock-specific actions.

Make the verification workflow step concrete by naming the actual checks (e.g., 'assert stub count and matched/unmatched requests via the journal') instead of 'Execute appropriate checks'.

DimensionReasoningScore

Conciseness

Mostly efficient with no over-explanation of basic concepts, but the 'When to use this skill' list duplicates triggers already in the description and the Workflow steps are generic process boilerplate ('Implement or refactor artifacts following the reference patterns') that could be trimmed.

3 / 5

Actionability

The body offers only high-level hints — no concrete WireMock mapping snippets, JSON examples, or Java DSL code; the only executable commands are meta-process maven invocations, with all real guidance deferred to the reference file.

2 / 5

Workflow Clarity

A clear four-step sequence (read reference, gather scope, apply changes, run verification) with explicit compile/verify checkpoints enforced in Constraints, though step 4's 'Execute appropriate checks' is vague.

4 / 5

Progressive Disclosure

SKILL.md is a well-structured overview that points to a single, confirmed-real one-level-deep reference (references/702-technologies-wiremock.md) with a clear Reference section and link, splitting detail appropriately.

5 / 5

Total

14

/

20

Passed

Description

95%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, comprehensive description with explicit what/when structure, rich natural trigger terms, and a clear scope boundary against sibling skills. The only ding is the second-person voice, which the rubric penalizes on specificity.

DimensionReasoningScore

Specificity

Lists many concrete capabilities (stub design, JSON/programmatic mappings, request matching, response bodies/faults, classpath fixtures, isolation/reset, verification, dynamic ports) for comprehensive coverage, but the second-person 'Use when you need...' voice triggers the mandated 1-point specificity reduction from a base of 5.

4 / 5

Completeness

Explicitly answers both 'what' (the capability list) and 'when' ('This should trigger for requests such as...' with four concrete trigger phrases), satisfying the top anchor.

5 / 5

Trigger Term Quality

Comprehensive natural terms with synonyms — 'WireMock stubs', 'JSON mappings or Java DSL', 'request matching', 'HTTP mocks', 'flaky tests', 'unmatched request journals', 'outbound HTTP calls' — matching phrases users would actually say.

5 / 5

Distinctiveness Conflict Risk

Clear niche (framework-agnostic WireMock stubbing) with an explicit boundary — 'without choosing Spring Boot, Quarkus, or Micronaut' — minimizing overlap with related integration-test skills.

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.

Repository
jabrena/plinth
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.