# Agentic SDLC with the Claude Code Plugin > Source: > Published: 2026-10-08 15:00:42+00:00 # Agentic SDLC with the Claude Code Plugin Updating code is usually the straightforward part of updating an API. It’s everything after that where things get messy. Which endpoints changed? Does the Postman collection still match the API? Does everything line up with the contract? And does the CI/CD pipeline need to be updated? If you miss any of that, you end up with a collection that looks right but isn’t. Then the next person opens it, assumes they can trust it, and wastes time trying to figure out why nothing matches. I wanted to see if an agent could handle that entire workflow using the [Claude Code Postman plugin](https://blog.postman.com/announcing-the-postman-plugin-for-claude-code/) and the [Context Graph](https://learning.postman.com/docs/use/context-graph/mcp-query). So I ran through it with Claude from start to finish: ``` API changes → Context Graph finds what needs updating → collection gets synced → lint checks the schema → a mock stands in for what isn't live yet → the mock confirms the tests work → CI runs them on every push ``` I did all of this through plain-English prompts in the terminal. I didn’t go through the endpoints one by one, file a separate ticket to update the collection, or circle back later to add the tests to CI. Claude handled the workflow as one connected task. ## Set up the plugin Let’s set up the plugin. You only have to do this once. First, install the plugin: ``` claude plugin install postman@claude-plugins-official ``` This installs the Postman plugin from Claude Code’s official marketplace and makes its skills available to Claude. It hasn’t connected to your repo or Postman workspace yet. You’re just installing the tooling. Next, go into the repo you want to work with and run: ``` postman init ``` This is the actual [setup step](https://learning.postman.com/docs/postman-cli/postman-cli-overview/). It handles a few things for you: - Installs the Postman CLI if you don’t already have it - Opens your browser so you can sign in to Postman, or uses `POSTMAN_API_KEY` if you already have one set - Asks which Postman workspace you want to connect to - Creates `.postman/resources.yaml` with the workspace ID, collections directory, and API specification path That `.postman/resources.yaml` file is what connects everything. Every other plugin skill, including discovery, testing, mocking, and CI integration, checks it before doing any work. Then, open Claude Code and search the skills list for “postman”: ``` /skills postman ``` Here’s the full list, 13 skills, and what each one actually does: - **postman:api-engineer:** The default entry point for API engineering work: designing, implementing, mocking, testing, monitoring, documenting, or deploying an API. You’ll use this one most of the time, and it hands off to whichever specialist below actually fits the request. - **postman:bootstrap:** Resolves the Postman CLI, authenticates when the task needs it, and manages the filesystem and workspace binding for the repo. This is what runs behind`postman init` , and every other skill depends on it having already run. - **postman:api-discovery:** Discovers and uses APIs from the web or from Postman. Finds and integrates public third-party APIs with Orbit, locates Postman entities with search, and uses the Context Graph to investigate dependencies, ownership, runtime behavior, and change impact across an API ecosystem. - **postman:api-testing:** Runs tests against an API from the command line: a single ad hoc request, a full collection of test assertions, or matching real captured app traffic against a collection’s contract. - **postman:api-mocking:** Stands up a fake backend that behaves like a real API, from a collection or an OpenAPI spec, running locally or pushed to Postman’s cloud for a durable URL, plus request-time scenario and status-code overrides for testing failure paths. - **postman:ci-integration:** Common CI integrations you can add as independent pass-or-fail gates: running a collection on every pull request, failing a build on a governance violation, or pushing to a cloud workspace after a merge to main. - **postman:api-monitoring:** Creates, schedules, and manages Postman Monitors, recurring checks against a live API, including ad hoc runs, run history for diagnosing failures, and self-hosted runners for APIs that live behind a private network. - **postman:ai-readiness:** Scores a collection or an OpenAPI spec for how well an AI agent can discover, understand, call, and recover from errors with it. Missing examples, undocumented errors, and ambiguous parameters all cost points. - **postman:api-documentation:** Generates filesystem-first, agent-friendly API documentation from a collection or a spec, ready to share with the rest of the team. - **postman:performance-testing:** Load-tests a collection with concurrent virtual users, a chosen load profile, and pass-or-fail thresholds on latency or error rate, run locally or on Postman’s cloud runners. - **postman:flows:** Runs, deploys, and debugs Postman Flows from the command line, including tracing a failed run back to the exact block that broke. - **postman:collection-schema-v3:** Not something you call directly. It’s the reference the other skills read before writing or editing a collection file by hand, or before debugging a lint failure. - **postman:postman-mcp-server:** Also not something you call directly. Background knowledge about Postman concepts and MCP tool selection that loads automatically whenever another skill needs it. You’ll notice that none of the prompts in this post call these skills by name. That’s intentional. You tell Claude what you’re trying to do, and `postman:api-engineer` hands the work to whichever specialist actually fits. ## Query the Context Graph My app had changed quite a bit. The frontend now had integrations with Nylas for calendar sync and Notion for meeting notes, along with a new appointment invite flow. The Postman collection had none of them. So I asked Claude: Validate my collection against the Context Graph. Make sure the collection reflects all of the new and updated endpoints. Claude sent the request to the discovery skill, which queried the [Context Graph](https://learning.postman.com/docs/use/context-graph/mcp-query). It found a few different kinds of problems: - Nylas showed up as a known external service, but the graph didn’t have any endpoint data for it yet. Notion wasn’t in the graph at all. - Three routes existed in the frontend but had no matching request in the collection: the appointment invite flow, the Nylas integration, and the Notion integration. - The `cancel appointment` request existed, but it was out of date and no longer matched the route handler. - Other requests, including `confirm appointment` and`sync appointment` , already matched the code. Claude left those alone. This is the kind of work that can easily take up an afternoon. You search the frontend for every fetch call, compare each one with the collection, and hope you notice the endpoint someone renamed six weeks ago. The Context Graph gave Claude a much better place to start. It could compare what was in the collection with the routes and services already connected in the graph, then focus on the gaps. [Introducing the Context Graph API](https://blog.postman.com/introducing-the-context-graph-api-one-map-of-your-api-ecosystem/) explains how that map gets built. There’s an important distinction here, though. The graph didn’t hand Claude a set of facts to copy directly into the collection. It gave Claude a list of likely gaps. Claude still opened the route handlers and verified each one before creating or changing any requests. I think of it like getting a tip from a teammate who knows roughly where the problem is. You don’t blindly trust it, but it saves you from searching the entire codebase before you can even start. ## Close the gaps and check the collection Once Claude had a list of what was missing or out of date, it asked if I wanted it to fix the collection. I said yes, but I also wanted it to check the work against the API contract: Yes, do that, and check everything against the API contract. Adding the missing requests gets the collection up to date, but checking them against the contract makes sure the methods, parameters, and request bodies actually match what the API expects. Claude went through the gaps one at a time. It added the missing appointment invite request, updated the stale `cancel appointment` request, added the Nylas and Notion integration requests, and created an Environment with the variables those integrations needed. The new appointment invite request looked something like this: ``` POST {{base_url}}/api/appointments Authorization: Bearer {{access_token}} Content-Type: application/json { "hostId": "usr_4f2a91", "inviteeEmail": "[email protected]", "startTime": "2026-10-02T15:00:00Z", "durationMinutes": 30, "calendarProvider": "nylas" } { "id": "appt_88ab21", "status": "invited", "hostId": "usr_4f2a91", "inviteeEmail": "[email protected]", "startTime": "2026-10-02T15:00:00Z", "calendarEventId": "nylas_evt_7f31c", "notionPageId": null } ``` Once everything was in the collection, Claude ran a schema check: ``` bash $ postman collection lint Linting collection "Scheduling API" against v3 schema... ✓ 12 requests validated ✓ 0 schema errors ✓ 0 warnings Lint passed. ``` There’s a small but important distinction here. `postman collection lint` checks that the collection follows Postman’s v3 collection schema. In other words, it makes sure the file is structured correctly and Postman can understand it. It does not prove that the collection matches the API. Claude checked that separately by comparing every frontend route with the collection. Each route now mapped to one request with the same method, parameters, and body shape as the handler. So at this point, I knew two things: the collection was valid Postman JSON, and it matched the code. The next step was checking it against what the app actually sends. ## Add tests, prove they work, and put them in CI Now that the collection matched the code and had a mock standing in for the pieces that weren’t live yet, I wanted tests that would prove it, not just describe it: Write tests for all the new endpoints and add them all to the CI/CD pipeline. The CI integration skill took the request and brought in the mocking skill where it was needed. First, Claude added test scripts to every new and updated request. The Nylas connect request started with a couple of basic checks: ``` js pm.test("Status code is 201", () => { pm.response.to.have.status(201); }); pm.test("Response includes a Nylas account ID", () => { const body = pm.response.json(); pm.expect(body).to.have.property("nylasAccountId"); }); ``` It added the same kind of coverage to the appointment, Nylas, and Notion requests. Then it added the contract-level assertions that check the actual response shape: ``` js pm.test("Response matches documented schema", () => { const body = pm.response.json(); const schema = pm.response.json().$schema || pm.collectionVariables.get("appointment_schema"); pm.response.to.have.status(201); pm.expect(body).to.have.property("id"); pm.expect(body).to.have.property("status"); pm.expect(body.status).to.be.oneOf([ "invited", "confirmed", "cancelled" ]); pm.expect(body).to.have.property("calendarEventId"); }); // Save a response example for docs and future contract checks pm.visualizer.set(pm.response.json()); ``` Before running those tests against a real environment, Claude generated a mock from the collection using the api-mocking skill. ``` Mock server running at http://localhost:4010 Running collection against mock... ✓ 12/12 requests passed ✓ 12/12 test scripts passed 0 failures ``` The api-mocking skill builds a working mock directly from the collection and its examples. That gave Claude a safe way to run every new test before pointing anything at the live API. More importantly, it proved the test scripts could actually run against the responses described by the contract. They weren’t just sitting in the collection looking complete. Once the tests passed against the mock, Claude added the collection run to GitHub Actions using the ci-integration skill: ``` name: API contract check on: pull_request: paths: - 'postman/**' - 'src/routes/**' jobs: contract-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Install the Postman CLI run: curl -o- "https://dl-cli.pstmn.io/install/linux64.sh" | sh - name: Lint the collection run: postman collection lint - name: Run the collection against staging run: postman collection run scheduling-api.json -e staging.json env: POSTMAN_API_KEY: ${{ secrets.POSTMAN_API_KEY }} ``` This is where the workflow stopped being something I ran once in my terminal. `postman collection run` now runs the same collection and test scripts on every relevant pull request. Claude tested the CI command locally before committing anything. Then it committed the new requests, the updated `cancel appointment` request, the Environment, the test scripts, and the GitHub Actions workflow before opening a pull request. The final PR covered the whole change, not just the frontend code. The collection now included the Nylas, Notion, and appointment requests. All 12 requests had test assertions and saved examples. And the CI job was ready to catch the next change that caused the code, collection, and contract to drift apart. ## Where this leaves you None of these steps is new. You could already lint a collection, mock an API, write tests, and update CI by hand. The difference is that Claude handled the whole workflow from one prompt, in the right order, without guessing what was missing. That’s where the Context Graph matters. An agent reading one repo can only see what’s in that repo. It can’t know that the frontend shipped an endpoint that never made it into the collection, or that an existing request drifted out of sync. The plugin gives Claude the tools to fix those problems. The Context Graph tells it where the problems are. Without the graph, Claude could lint an incomplete collection and get a clean result because lint checks whether the file is valid, not whether it reflects the real API. Try it with a change you know your collection missed: Validate my collection against the Context Graph. Then compare what it finds with how long it would have taken you to find by hand.