How do I install the Breaking Change Report skill?

Run npx skillmds@latest add wiremock/breaking-change-report in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Breaking Change Report safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Breaking Change Report?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Breaking Change Report free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Breaking Change Report?

wiremock (@wiremock) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Breaking Change Report by wiremock — Agent Skill

Name: Breaking Change Report
Author: wiremock

Breaking Change Report

Run the japicmp binary-compatibility report for wiremock-core and produce a filtered summary covering only @PublishedAPI-annotated classes. Use this when asked to generate, refresh, or summarise the breaking-changes report.

wiremock 426ad5e 2.7 KB Updated Sep 17, 2026

File contents

Generate a filtered breaking-change summary for @PublishedAPI-annotated classes by following these steps in order.

1 — Run the report

./gradlew :wiremock-core:japicmp --no-daemon -q

If the build fails, diagnose and fix before continuing.

2 — Collect the published API surface

Run this to get the fully-qualified class names of every @PublishedAPI-annotated type:

grep -rl "@PublishedAPI" wiremock-core/src/main/java --include="*.java" \
  | sed 's|.*/java/||; s|\.java$||; s|/|.|g' | sort

Keep this list in mind — it is the filter for the next step.

3 — Read the raw report

Read the full text report at:

wiremock-core/build/reports/japicmp/breaking-changes.txt

4 — Produce the filtered summary

Cross-reference the raw report against the @PublishedAPI class list. Include an entry if:

The class name matches a @PublishedAPI class exactly, or
The class is a public inner class of a @PublishedAPI class (indicated by $ in the name).

Exclude entries where the only change is the class-file format version bump (Java version upgrade) — note this once at the top of the output instead.

Write the filtered summary as Markdown to:

wiremock-core/build/reports/japicmp/breaking-changes-published-api.md

Use the following structure:

# Breaking changes in published API — WireMock <old-version> → <new-version>

> Java class-file version bump (X → Y) affects every class; Java N is now
> the minimum runtime.

---

## <Logical group (e.g. Core server & configuration)>

### `ClassName`
- **Removed method** `methodSignature()`
- **Return type changed** `method()`: `OldType` → `NewType`
- ...

(repeat per class, grouped sensibly)

Group classes by area rather than listing them alphabetically:

Core server & configuration (WireMockServer, WireMockConfiguration, Options, MappingsSaver)
Client DSL (WireMock, WireMockBuilder, etc.)
Stub mapping model (StubMapping, StubMappings, etc.)
HTTP model (ResponseDefinition, Request, RequestMethod, etc.)
Extension SPI (StubLifecycleListener, HttpServerFactory, etc.)
Common / shared types (Metadata, Parameters, etc.)
Recording API (SnapshotRecordResult, SnapshotOutputFormatter, etc.)
Any other areas that have changes

Omit groups that have no breaking changes in @PublishedAPI classes.

Once the file is written, print the path and a one-line count of how many @PublishedAPI classes had breaking changes.

---name: breaking-change-reportdescription: Run the japicmp binary-compatibility report for wiremock-core and produce a filtered summary covering only @PublishedAPI-annotated classes. Use this when asked to generate, refresh, or summarise the breaking-changes report.---Generate a filtered breaking-change summary for `@PublishedAPI`-annotated classes by following these steps in order.## 1 — Run the report```bash./gradlew :wiremock-core:japicmp --no-daemon -q```If the build fails, diagnose and fix before continuing.## 2 — Collect the published API surfaceRun this to get the fully-qualified class names of every `@PublishedAPI`-annotated type:```bashgrep -rl "@PublishedAPI" wiremock-core/src/main/java --include="*.java" \ | sed 's|.*/java/||; s|\.java$||; s|/|.|g' | sort```Keep this list in mind — it is the filter for the next step.## 3 — Read the raw reportRead the full text report at:```wiremock-core/build/reports/japicmp/breaking-changes.txt```## 4 — Produce the filtered summaryCross-reference the raw report against the `@PublishedAPI` class list. Include an entry if:- The class name matches a `@PublishedAPI` class exactly, **or**- The class is a public inner class of a `@PublishedAPI` class (indicated by `$` in the name).Exclude entries where the only change is the class-file format version bump(Java version upgrade) — note this once at the top of the output instead.Write the filtered summary as Markdown to:```wiremock-core/build/reports/japicmp/breaking-changes-published-api.md```Use the following structure:```# Breaking changes in published API — WireMock <old-version> → <new-version>> Java class-file version bump (X → Y) affects every class; Java N is now> the minimum runtime.---## <Logical group (e.g. Core server & configuration)>### `ClassName`- **Removed method** `methodSignature()`- **Return type changed** `method()`: `OldType` → `NewType`- ...(repeat per class, grouped sensibly)```Group classes by area rather than listing them alphabetically:- Core server & configuration (`WireMockServer`, `WireMockConfiguration`, `Options`, `MappingsSaver`)- Client DSL (`WireMock`, `WireMockBuilder`, etc.)- Stub mapping model (`StubMapping`, `StubMappings`, etc.)- HTTP model (`ResponseDefinition`, `Request`, `RequestMethod`, etc.)- Extension SPI (`StubLifecycleListener`, `HttpServerFactory`, etc.)- Common / shared types (`Metadata`, `Parameters`, etc.)- Recording API (`SnapshotRecordResult`, `SnapshotOutputFormatter`, etc.)- Any other areas that have changesOmit groups that have no breaking changes in `@PublishedAPI` classes.Once the file is written, print the path and a one-line count of how many`@PublishedAPI` classes had breaking changes.

Frequently asked questions