/wiremock-standalone-docker
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,
$ npx -y skills add giuseppe-trisciuoglio/developer-kit --skill wiremock-standalone-docker --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/wiremock-standalone-docker
Context preview
The summary Claude sees to decide when to auto-load this skill.
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,
SKILL.md
wiremock-standalone-docker.SKILL.mdname: 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:
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
docker compose up -d
Step 5: Verify WireMock is Running
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
{
"request": { "method": "GET", "url": "/api/users/123" },
"response": {
"status": 200,
"jsonBody": { "id": 123, "name": "Mario Rossi" }
}
}Example 2: Mock Server Error
{
"request": { "method": "GET", "url": "/api/error" },
"response": { "status": 500, "body": "Internal Server Error" }
}Example 3: Mock Timeout
{
"request": { "method": "GET", "url": "/api/slow" },
"response": {
"status": 200,
"fixedDelayMilliseconds": 5000,
"jsonBody": { "message": "delayed" }
}
}Example 4: Docker Compose with Application
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:
- wiremockBest 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
Read more
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:
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
docker compose up -d
Step 5: Verify WireMock is Running
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
{
"request": { "method": "GET", "url": "/api/users/123" },
"response": {
"status": 200,
"jsonBody": { "id": 123, "name": "Mario Rossi" }
}
}Example 2: Mock Server Error
{
"request": { "method": "GET", "url": "/api/error" },
"response": { "status": 500, "body": "Internal Server Error" }
}Example 3: Mock Timeout
{
"request": { "method": "GET", "url": "/api/slow" },
"response": {
"status": 200,
"fixedDelayMilliseconds": 5000,
"jsonBody": { "message": "delayed" }
}
}Example 4: Docker Compose with Application
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:
- wiremockBest 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
Modular plugin marketplace for Claude Code and agentic CLIs, with validated, spec-driven skills, agents, commands, and workflows for Java, TypeScript, Python, PHP, AWS, and AI.
Repo: giuseppe-trisciuoglio/developer-kit
Other skills on developer-kit.
- /chunking-strategy
Provides chunking strategies for RAG systems. Generates chunk size recommendations (256-1024 tokens), overlap percentages (10-20%), and semantic boundary detection methods. Validates semantic coherence and evaluates retrieval precision/recall metrics. Use when building
Open skill - /prompt-engineering
Provides workflows to write, debug, and optimize prompts for LLMs, including few-shot example selection, chain-of-thought structuring, system prompt design, and template composition. Use when the user asks to write or improve a prompt, wants help with few-shot examples,
Open skill - /rag
Implements document chunking, embedding generation, vector storage, and retrieval pipelines for Retrieval-Augmented Generation systems. Use when building RAG applications, creating document Q&A systems, or integrating AI with knowledge bases.
Open skill - /aws-cloudformation-auto-scaling
Provides AWS CloudFormation patterns for Auto Scaling including EC2, ECS, and Lambda. Use when creating Auto Scaling groups, launch configurations, launch templates, scaling policies, lifecycle hooks, and predictive scaling. Covers template structure with Parameters, Outputs,
Open skill - /aws-cloudformation-bedrock
Provides AWS CloudFormation patterns for Amazon Bedrock resources including agents, knowledge bases, data sources, guardrails, prompts, flows, and inference profiles. Use when creating Bedrock agents with action groups, implementing RAG with knowledge bases, configuring vector
Open skill - /aws-cloudformation-cloudfront
Provides AWS CloudFormation patterns for CloudFront distributions, origins (ALB, S3, Lambda@Edge, VPC Origins), CacheBehaviors, Functions, SecurityHeaders, parameters, Outputs and cross-stack references. Use when creating CloudFront distributions with CloudFormation, configuring
Open skill

