Implementation starts with the requests your tests and mocks will reuse. The collection-schema-v3 skill covers how a collection is stored as per-request YAML files, and the variables skill keeps target configuration out of those files so one collection can run against any environment.

1. Ask Claude Code:

   ✦copy

   ›

   Add a "Get animated movie by ID" request to my Movies API collection for `GET /movies/animation/{{id}}` with an `id` collection variable defaulting to 1. Then create a "Local" environment with a `base_url` variable of `https://api.sampleapis.com`, switch every request in the collection to use `{{base_url}}`, and lint the collection and the environment.

   Paste this into your agent

2. Review the diff. Confirm the new request is its own *.request.yaml file, no request still hard-codes the host, the id variable lives in .resources/definition.yaml, and postman/environments/ contains Local.environment.yaml.

3. The new request needs its own test and examples — the mock and the tests in later steps are built from them. Ask Claude Code:

   ✦copy

   ›

   Give the "Get animated movie by ID" request a status-code test and two saved examples, a 200 for id 1 and a 404 for an unknown id, using real responses from the live API. Lint the collection when you are done.

   Paste this into your agent

4. Confirm the request now has an afterResponse script and two example files. The live API returns 404 with an empty {} body for an unknown id.

A mock lets you build and test against the API without depending on the live service. The api-mocking skill generates a local mock from your collection, and postman mock run serves it with no sign-in required.

1. Ask Claude Code:

   ✦copy

   ›

   Generate a mock of the Movies API from my collection, run it locally, and call `GET /movies/animation` and `GET /movies/animation/1` against it. Also trigger the 404 example and show me what comes back.

   Paste this into your agent

2. Confirm Claude runs postman mock generate and postman mock run, prints the local URL it bound, and gets back the movie list, the movie with id 1, and the documented 404 ({}).

3. Check that a postman/mocks/<name>/ folder with a config.yaml and default.js handler now exists in your project.

4. Read Claude's list of differences from the real API — a generated mock replays your saved examples, so expect these:

   • The 404 only comes back when a request sends the header x-mock-response-code: 404. A bad id with no header still returns the saved 200.
   • The list holds only the movies in your saved example, even though X-Total-Count says 96.
   • Nothing is stateful. Regenerating with --update overwrites hand edits to default.js.

Real services call other services. The api-simulation skill runs your actual code against mocks of the HTTP APIs it depends on, so you can prove a change works end to end — and see what happens when a dependency fails — without touching the real thing. It needs Postman CLI 1.70.0 or later, so check postman --version.

1. Ask Claude Code:

   ✦copy

   ›

   Create a tiny Node service in a `catalog-service/` folder with one route, `GET /top-animated`, that calls the Movies API and returns the first three titles. Build a simulation that uses my Movies API mock as the service's dependency, run the service against it, confirm `GET /top-animated` returns a 200 with three titles, and show me from the simulation log that the mock was called.

   Paste this into your agent

2. Confirm Claude creates a .sim.yaml under postman/simulations/, runs postman simulation run, and points the service's base URL at the simulation instead of the live API (the simulation serves each mock under its route key, for example http://localhost:4900/movies-api).

3. Check the happy path first: GET /top-animated must return 200 with three movie titles, and the simulation log must show exactly one request event for GET /movies/animation served by the Movies API mock. A run that returns anything other than 200 isn't done yet — ask Claude to fix the wiring (a base URL missing its route key is the usual cause).

4. Now break the dependency. Ask Claude Code:

   ✦copy

   ›

   Run the service again with the Movies API returning a 500 error and with it timing out. Tell me what the service does in each case and whether it handles the failure well.

   Paste this into your agent

5. Review what Claude found. Expect a clean 502 from the service in both cases — it should stay up and answer other requests. Injected failures are answered by the simulation itself, so they don't appear as mock requests in the log. A service with no timeout or error logging is a finding worth fixing.