Update to Postman

{
  "description": "Use when testing an endpoint, running collection assertions, or checking real application traffic against an API contract. Reuses saved requests and reports what live, mocked, or captured-traffic results actually establish. Use for requests such as \"test this endpoint\".",
  "included_files": [],
  "name": "api-testing",
  "skill_md_contents": "---\nname: api-testing\ndescription: Use when testing an endpoint, running collection assertions, or checking real application traffic against an API contract. Reuses saved requests and reports what live, mocked, or captured-traffic results actually establish. Use for requests such as \"test this endpoint\".\n---\n\n# API Testing\n\nSaved requests preserve the auth, payloads, variables, and assertions that make\nan API check reproducible. The useful result is evidence about an intended\nguarantee; a successful HTTP exchange alone does not establish correctness.\n\n1. Choose the smallest execution mode that answers the question:\n\n   | Evidence needed | Use |\n   | --- | --- |\n   | One endpoint with no saved request | `postman request <url>` |\n   | Behavior of an existing saved request | `postman collection run <collection-path> -i <request-id-name-or-path>` |\n   | Reusable regression checks | `postman collection run <path-or-id>` |\n   | Whether a real app's calls match the contract | `postman application test` |\n\n2. Reuse a matching request under `postman/collections/` before reconstructing\n   its HTTP fields. Running it through the collection retains inherited auth,\n   variables, and scripts. `postman request` takes a URL, not a request YAML\n   path; for an unsaved request with an existing payload file, `--body @path`\n   preserves that file as the source. See **collection-schema-v3** when\n   editing the saved request.\n3. Derive assertions from the contract and the behavior at risk. A test that\n   merely repeats the current implementation can bless its bug. Preserve\n   existing guarantees and add checks for the changed behavior; put reusable\n   `pm.test` assertions in the collection so later runs and teammates inherit\n   them. Inline `--script-post-request` assertions suit a one-off check.\n4. Choose a real or mocked target according to the claim. `--use-mock` lets a\n   collection run exercise request and assertion logic without a live\n   backend; `--mock` alone only starts one. `--use-mock` replaces the\n   variable's whole value, base path included (see **api-mocking**). Passing\n   against that mock does not verify the service the mock stands in for.\n5. Reuse environment resolution with `-e` and **variables**. Use a CSV/JSON\n   file through `-d` for simple iteration; use **datasets** when the inputs\n   need queries, joins, or reusable views. Export reports such as\n   `-r junit,html` when **ci-integration** needs evidence beyond terminal output.\n6. Use `application test` when the application's actual traffic is the subject.\n   It runs an existing command, such as `--command \"npx playwright test\"`,\n   captures its traffic, and matches it against collections. `--capture-only`\n   instead exports a v3 collection organized by host; that captures behavior\n   without validating it. Results are recorded in the connected workspace by\n   default; `--report-events=false` keeps the run local when required.\n\nUse command-specific `-h` for supported options. Workspace resources need a\nsigned-in CLI; a bare URL or local collection does not require a workspace\nbinding.\n\n## Verification\n\nReport the target, tested behavior, assertion counts, and exit code. The exit\ncode reflects failed assertions, not HTTP status alone: a 200 can fail a test.\nFor application testing, distinguish matching from capture-only mode, and for\nmocked runs state which real behavior remains unverified.\n"
}