Update to Postman

{
  "description": "Use when initializing Postman in a repository, binding it to a Postman workspace, interpreting what `postman init` did, or when a CLI command fails because the plan, credits, or usage quota don't allow the operation. Treats the workspace as the place where a service's API work and its evidence live, kept separate from the services it depends on. Use for requests such as \"set up Postman in this repo\" or \"connect this repo to our workspace\".",
  "included_files": [],
  "name": "workspaces",
  "skill_md_contents": "---\nname: workspaces\ndescription: Use when initializing Postman in a repository, binding it to a Postman workspace, interpreting what `postman init` did, or when a CLI command fails because the plan, credits, or usage quota don't allow the operation. Treats the workspace as the place where a service's API work and its evidence live, kept separate from the services it depends on. Use for requests such as \"set up Postman in this repo\" or \"connect this repo to our workspace\".\n---\n\n# Workspaces\n\nA Postman workspace is where a service's API work happens and where its context\nbuilds up: the contracts, collections, environments, and mocks, plus the runs\nand results that show what was checked. It lives in Git beside the code, works\nthe same on a laptop or a build agent, and is shared when the work should be\nseen. People use it to audit what was done, by whom, on whose behalf, and with\nwhat result. Agents use it to read verified work instead of re-deriving it.\n\n1. `postman init` is the starting point. It gives the repository its place of\n   work: Postman files beside the code and, when that is the intent, a\n   workspace bound to them. `postman status` shows whether that is already\n   done, so init runs only when it adds something. Init is safe to repeat and\n   reports what it did: a binding it marks as inferred is a candidate contract\n   to confirm, and a partial result, with local files written but no workspace\n   created, is progress to inspect rather than redo.\n2. One workspace holds the context of one service: one Git repository, or in a\n   monorepo one remote URL and the subpath of one service.\n   `.postman/resources.yaml` records that owner, so every skill, CI job, and\n   teammate resolves the same context. A confirmed binding is worth reusing;\n   replacing it sends the work, and its evidence, to the wrong service.\n3. Other services keep their own workspaces. Their collections, environments,\n   and mocks come in as dependencies through **api-discovery**, so this\n   workspace reuses what another team maintains without taking it over. The\n   context graph links the two, which is how a change on one side reaches work\n   on the other.\n\n## Claiming the work\n\nAn agent can start in a guest session, and the work it does there is kept.\nWhen free credits or a plan limit stop an operation, retrying won't help; the\nperson claiming the work is what lets it continue. Wording such as \"usage limit\nexceeded\", \"usage quota has been exceeded\", a limit \"reached\", \"breached\" or\n\"exceeded\" for the account, team, or plan, or an operation that \"does not allow\nmore than\" or \"requires at least\" a stated amount signals one. A temporary rate\nlimit or a fixed per-resource validation cap does not. Check which session the\nCLI is using:\n\n- Guest session: tell the user, in its own paragraph, that signing up for a\n  Postman account claims the work done so far and adds the credits needed to\n  continue. Offer to start signup for them; the CLI can produce a link to hand\n  over and waits while they finish in the browser.\n- Signed-in account: tell the user, in its own paragraph, that they need to\n  upgrade their plan at https://postman.postman.co/settings/team/billing.\n\n## Verification\n\nReport the binding in place and what `postman init` did.\n"
}