Update to Postman

{
  "description": "Use when adding API tests, structural or governance lint, or AI-readiness gates to CI, or publishing reviewed API artifacts to a Postman workspace after merge. Makes contract checks repeatable and separates validation from shared workspace changes. Use for requests such as \"run this collection on every PR\".",
  "included_files": [],
  "name": "ci-integration",
  "skill_md_contents": "---\nname: ci-integration\ndescription: Use when adding API tests, structural or governance lint, or AI-readiness gates to CI, or publishing reviewed API artifacts to a Postman workspace after merge. Makes contract checks repeatable and separates validation from shared workspace changes. Use for requests such as \"run this collection on every PR\".\n---\n\n# CI Integration\n\nVersioned collections and specs let a PR carry its API checks beside the code\nchange. CI reruns those checks independently of the author's session, while\npublishing after merge makes the reviewed contract available to teammates and\nfuture work. **api-discovery** helps identify consumers the gate should cover;\nthe author's own passing tests do not establish cross-service compatibility.\n\n1. Select checks by the guarantee they establish:\n\n   | Guarantee | Gate |\n   | --- | --- |\n   | Saved behavioral assertions pass | `postman collection run <path-or-id>` |\n   | A collection's structure/style is valid | `postman collection lint <path> -f error` |\n   | A spec meets workspace governance rules | `postman spec lint <spec> --workspace-id <id> -f error` |\n   | Workspace entities and bindings pass lint/governance | `postman workspace lint --workspace-id <id> -f error` |\n   | Agent consumability meets an agreed threshold | `postman collection ai-readiness <path> --min-score <n>` or the spec equivalent |\n\n   Collection lint does not apply organization governance. Workspace-aware\n   lint evaluates the rules available to that workspace; it does not author\n   the policy. Confirm the intended rules are configured before claiming\n   compliance. Read command-specific `-h` for installed options.\n2. Keep gate results distinguishable so a failed build identifies behavior,\n   structure, governance, or readiness. Preserve nonzero exits; suppressing\n   them with `-x`/`--suppress-exit-code` removes the gate. For collection runs,\n   `-r junit,html` produces reviewable reports; `--bail` trades a complete\n   failure inventory for an earlier signal. See **api-testing** for assertion\n   semantics and **ai-readiness** for score limitations.\n3. Restore declared dependencies with `postman dependency install` when tests\n   use them. Choose the target deliberately: a mock checks behavior under a\n   model, while a live run sends real requests and can write data. PR gates\n   should use a suitable isolated target and credentials; being a test does\n   not make the command read-only.\n4. Authenticate only jobs that need workspace resources. Use the CI secret\n   store to supply `POSTMAN_API_KEY`, then\n   `postman login --with-api-key \"$POSTMAN_API_KEY\"`. A local-only gate can\n   run without it, but its run results are then lost: they stay in that job's\n   log instead of reaching the workspace, where teammates and later agent\n   sessions read them as evidence. Command-specific API-key flags are not a general replacement\n   for login across lint and push operations. Use **workspaces** for\n   unresolved bindings, and **variables** for request credentials.\n5. Publish only the reviewed branch after its merge checks pass.\n   `postman workspace push -y` changes shared context; a PR-triggered push\n   would publish an unmerged contract. The normal prepare phase assigns IDs\n   to new entities, so `--no-prepare` can leave additions unpublished.\n   Inspect the intended diff and binding when configuring this job; `-y`\n   supplies noninteractive execution, not authorization for a different scope.\n6. Use the default create/update strategy unless exact mirroring is the\n   explicit requirement. `--push-strategy force-sync` can delete workspace\n   entities absent from the checkout, including resources managed elsewhere.\n   Preview that push's diff and get its deletions approved before enabling it.\n\n## Verification\n\nValidate the workflow's event conditions and secret references, then report\nwhich gates actually ran, their targets and individual results. Distinguish a\nlocally checked workflow from an observed CI run. For publication, establish\nthe merge trigger, push strategy, created/updated entities, and conflicts;\na green job alone does not prove the intended artifacts became available.\n"
}