The deploy stage makes everything above repeatable. The ci-integration skill adds PR gates for your tests, lint, and AI readiness, and postman workspace push publishes the reviewed work back to your workspace so teammates and future agent sessions inherit it.

1. Ask Claude Code:

   ✦copy

   ›

   Add a GitHub Actions workflow that, on every pull request, lints the collection and environment, runs the collection against the mock, and fails if the AI readiness score drops below the score we just reached. Publish to the workspace with `postman workspace push` only after merge to main. Don't push anything yet — show me the diff first.

   Paste this into your agent

2. Review .github/workflows/. Confirm the push step runs only on main after the checks pass, each gate (lint, tests against the mock, readiness) is a separate step so a failure says which kind it was, the tests use --use-mock so no CI request reaches the live API, and the API key comes from a CI secret (POSTMAN_API_KEY), not a committed file.

3. The workflow only runs once it's in a GitHub repo, which this module doesn't push to. Check the gates yourself instead: ask Claude to run the lint, mock run, and readiness commands from the workflow locally and report the exit codes. The readiness gate should pass at your current score and fail if the threshold is set above it.

4. Publish your work. The CLI has no message flag for postman workspace push, so describe the change in a normal Git commit first. Ask Claude Code:

   ✦copy

   ›

   Preview the publish with `postman workspace diff`. Then commit this work to Git with a message describing what we built, and push it to my workspace with `postman workspace push`. Do not push the Git repository anywhere.

   Paste this into your agent

5. Confirm the diff shows no deletions and the push reports your collection, environment, mock, and simulations as updated or created. The mock and simulations always show as "will push" because the CLI can't compare them, and the collection may still show as modified after a successful push — that's expected.

6. Open your [Your Name] - AI Basics workspace in Postman and confirm the new examples, mock, and tests are there. Anything Claude created along the way (such as extra simulation variants) is published too.

Shipping isn't the end of the lifecycle. A passing test run is a snapshot; a monitor turns the same collection into recurring evidence that the live API still behaves. The api-monitoring skill reuses the assertions you wrote in the test stage.

1. Ask Claude Code:

   ✦copy

   ›

   Create a monitor for my Movies API collection that runs once a day against the live API, then show me the result of the first run.

   Paste this into your agent

2. Confirm Claude runs postman monitor create, sets an explicit timezone and hosted region, and inspects the first run with postman monitor jobs get or postman monitor runs get.

3. A monitor runs the pushed copy of the collection with the workspace's Local environment, which is why you published in the previous step. Expect the first run to send two requests to the live API, return 200 for both, and pass every assertion. Creating the monitor also starts that first run.

4. Ask Claude what the monitor doesn't cover. Your collection has no failing-case request, so a change to the 404 behavior would go unnoticed.

If a command fails with a plan or usage-limit message, follow Claude's guidance rather than retrying — it's a subscription limit, not a bug in your setup.