Skip to main content
skill CX Codex

wiremock-standalone-docker — Claude Code skill: WireMock in Docker

Runs WireMock as its own Docker container and writes stub mappings for external APIs: success, 5xx, timeouts and rate limits.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add giuseppe-trisciuoglio/developer-kit --skill wiremock-standalone-docker -a claude-code
Open on GitHub

What wiremock-standalone-docker does

The skill lays out a working sequence. First the agent writes docker-compose.yml around the wiremock/wiremock:3.5.2 image with port 8080 and a bind mount for ./wiremock. Then it creates mappings/ and __files/, then fills in a JSON stub for every scenario you need. File edits run through Read, Write and Edit, while startup and checks go through Bash.

Delays are expressed with fixedDelayMilliseconds inside a response. For a rate limit the stub returns 429 plus a Retry-After header. Loaded stubs are listed at curl http://localhost:8080/__admin/mappings, the /__admin/requests endpoint shows what actually arrived, and /__admin/reset clears state between runs. Your app points at http://localhost:8080, or at http://wiremock:8080 when both live in the same Docker network.

Port 8080 has to be free; if something else holds it, remap the port. Stub files also vanish on container restart, so keep them in git. Dynamic bodies need the --global-response-templating flag at startup, and without it template placeholders stay as plain text.

What it helps with

  • stand up a fake external API without touching the real service
  • replay a 500 or 429 and exercise the error path
  • check client retry behaviour against an artificial delay
  • pin an API contract before the real implementation exists
  • keep a reproducible test environment in docker-compose

Example prompts for the agent

  • Add a stub in wiremock/mappings for GET /api/users/123 that answers 200 with a JSON user.
  • Create a stub for /api/slow with a 5000 ms delay so I can test the client timeout.
  • Run curl http://localhost:8080/__admin/mappings and show me which stubs are loaded.

How to install wiremock-standalone-docker

1Skills CLI (Vercel)

npx skills add giuseppe-trisciuoglio/developer-kit --skill wiremock-standalone-docker -a claude-code

2Manually: put the files in place

~/.claude/skills/wiremock-standalone-docker/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/wiremock-standalone-docker/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about wiremock-standalone-docker

How do I install wiremock-standalone-docker in Claude Code?

Run npx skills add giuseppe-trisciuoglio/developer-kit --skill wiremock-standalone-docker -a claude-code. The skill file lands at ~/.claude/skills/wiremock-standalone-docker/SKILL.md.

What does wiremock-standalone-docker do?

It gives the agent a setup for WireMock in a standalone Docker container: the compose file, the folder layout and JSON stubs covering happy paths, errors, delays and rate limits.

Why do my requests not match any stub?

Query curl http://localhost:8080/__admin/requests to see exactly what reached the server. A wrong path or HTTP method in the stub JSON is the usual cause.

Source text

SKILL.md · MIT
---
name: wiremock-standalone-docker
description: Provides patterns and configurations for running WireMock as a standalone Docker container. Generates mock HTTP endpoints, creates stub mappings for testing, validates integration scenarios, and simulates error conditions. Use when you need to mock APIs, create a mock server, stub external services, simulate third-party APIs, or fake API responses for integration testing.
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
---

# WireMock Standalone Docker Skill

## Overview

Provides patterns for running WireMock as a standalone Docker container to mock external APIs during integration and end-to-end testing. Runs WireMock as a separate service that simulates real API behavior for testing HTTP clients, retry logic, and error handling.

## When to Use

Use when you need to:
- Mock external APIs during integration or end-to-end testing
- Simulate error conditions (timeouts, 5xx, rate limiting) without real services
- Test HTTP client configurations, retry logic, and error handling
- Create portable, reproducible test environments
- Validate API contracts before implementing the real service

## Instructions

### Step 1: Set Up Docker Compose

Create a `docker-compose.yml` with WireMock 3.5.2, port mapping, and volume mounts for mappings and files:

```yaml
version: "3.8"
services:
  wiremock:
    image: wiremock/wiremock:3.5.2
    ports:
      - "8080:8080"
    volumes:
      - ./wiremock:/home/wiremock
    command: ["--global-response-templating"]
```

### Step 2: Create Directory Structure

Create the WireMock configuration directories:

```
wiremock/
├── mappings/   # JSON stub definitions
└── __files/   # Response body files
```

### Step 3: Define API Mappings

Create JSON stub files in `wiremock/mappings/` for each scenario:

- **Success**: Return 200 with JSON body
- **Not Found**: Return 404
- **Server Error**: Return 500
- **Timeout**: Use `fixedDelayMilliseconds`
- **Rate Limit**: Return 429 with Retry-After header

### Step 4: Start WireMock

```bash
docker compose up -d
```

### Step 5: Verify WireMock is Running

```bash
curl http://localhost:8080/__admin/mappings
```

Expected: Returns empty array `{"mappings":[]}` if no stubs loaded, or your stub definitions. If you get connection refused, check that the container is running: `docker compose ps`

### Step 6: Configure HTTP Client

Point your application to `http://localhost:8080` (or `http://wiremock:8080` in Docker network) instead of the real API.

### Step 7: Test Edge Cases

Always test: 200, 400, 401, 403, 404, 429, 500, timeouts, malformed responses.

## Examples

### Example 1: Mock Successful GET Request

```json
{
  "request": { "method": "GET", "url": "/api/users/123" },
  "response": {
    "status": 200,
    "jsonBody": { "id": 123, "name": "Mario Rossi" }
  }
}
```

### Example 2: Mock Server Error

```json
{
  "request": { "method": "GET", "url": "/api/error" },
  "response": { "status": 500, "body": "Internal Server Error" }
}
```

### Example 3: Mock Timeout

```json
{
  "request": { "method": "GET", "url": "/api/slow" },
  "response": {
    "status": 200,
    "fixedDelayMilliseconds": 5000,
    "jsonBody": { "message": "delayed" }
  }
}
```

### Example 4: Docker Compose with Application

```yaml
services:
  wiremock:
    image: wiremock/wiremock:3.5.2
    ports:
      - "8080:8080"
    volumes:
      - ./wiremock:/home/wiremock

  app:
    build: .
    environment:
      - API_BASE_URL=http://wiremock:8080
    depends_on:
      - wiremock
```

## Best Practices

1. **Organize mappings by feature**: Use subdirectories like `users/`, `products/`
2. **Version control mappings**: Keep mappings in git for reproducible tests
3. **Test all error scenarios**: 401, 403, 404, 429, 500, timeouts
4. **Reset between test runs**: `curl -X POST http://localhost:8080/__admin/reset`
5. **Use descriptive file names**: `get-user-success.json`, `post-user-error.json`

## Constraints and Warnings

- Ensure port 8080 is available or map to a different port
- Configure Docker networking when running multiple containers
- Enable `--global-response-templating` for dynamic responses
- WireMock resets mappings on container restart

## Troubleshooting

**Requests don't match stubs?**
Check what WireMock received: `curl http://localhost:8080/__admin/requests` — shows unmatched requests with details about what was actually sent.

**Stub file not loading?**
Verify file location: place JSON stubs in `wiremock/mappings/` and response files in `wiremock/__files/`. Check file permissions.

**Connection refused errors?**
Run `docker compose ps` to verify the container is running. Check port conflicts with `lsof -i :8080`.

## References

See `references/` for complete examples:
- `docker-compose.yml` - Full Docker Compose configuration
- `wiremock/mappings/` - Complete stub examples for all scenarios

© giuseppe-trisciuoglio · MIT · giuseppe-trisciuoglio/developer-kit

Similar skills

All skills for Testing and QA →

From the same set96

docs-updater The skill diffs your branch against the last release tag and updates README, CHANGELOG and documentation folders. Handy before a release or a pull request. CX Codex +1 3,500installs spring-boot-project-creator Generates a Spring Boot 3.x or 4.x project via Spring Initializr with DDD or layered architecture. Handy when bootstrapping a Java microservice with JPA, OpenAPI, and Docker Compose. CX Codex +1 3,500installs aws-lambda-php-integration A skill that walks the agent through running PHP and Symfony on AWS Lambda with Bref: handlers, runtime layers, SQS/SNS triggers and cold start tuning. CX Codex +1 3,500installs aws-lambda-java-integration A skill with ready patterns for Java Lambda functions: Micronaut or raw handlers, cold start tuning, and Serverless or SAM deployment. CX Codex +1 3,500installs codex Delegates complex code generation, refactoring, and code reviews to the Codex CLI using GPT-5.3-codex, o3, or o4-mini models. CX Codex +1 3,400installs copilot-cli Hands tasks from Claude to GitHub Copilot CLI in non-interactive mode, with model choice, permission flags and markdown session export. CX Codex +1 3,400installs gemini Hands large-context analysis and complex reasoning to Gemini CLI, then brings the result back for your approval. CX Codex +1 3,400installs adr-drafting Drafts Architecture Decision Records for significant technical choices, matching existing repository conventions. Helpful when documenting database migrations or service boundaries. CX Codex +1 3,400installs

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor