Update to Postman

{
  "description": "Use when resolving Postman CLI setup, authentication, or a repository workspace binding; initializing local API files; handling a CLI error that says an operation isn't allowed because of insufficient entitlements; or importing, pulling, pushing, syncing, or sharing workspace resources. Reuses existing context and chooses sync direction without duplicating a workspace or rebinding a dependency. Use for requests such as \"set up Postman for this repo\".",
  "included_files": [
    {
      "relative_path": "reference/cli_installation.md",
      "size_in_bytes": 1724
    }
  ],
  "name": "bootstrap",
  "skill_md_contents": "---\nname: bootstrap\ndescription: Use when resolving Postman CLI setup, authentication, or a repository workspace binding; initializing local API files; handling a CLI error that says an operation isn't allowed because of insufficient entitlements; or importing, pulling, pushing, syncing, or sharing workspace resources. Reuses existing context and chooses sync direction without duplicating a workspace or rebinding a dependency. Use for requests such as \"set up Postman for this repo\".\n---\n\n# Bootstrap Postman for This Repo\n\nA local Postman project puts contracts, runnable requests, environments, and\nmocks beside implementation code so they can be inspected, diffed, and reviewed\nin a PR. A workspace binding connects that work to maintained shared context.\nSetup is useful when it resolves a missing capability or binding; a local API\ncheck does not need a new workspace merely to proceed.\n\n## Start with postman init\n\n`postman init` is idempotent and safe to run in any project, including one\nalready initialized. You can run it before API engineering work to scaffold the\nrelevant `postman/` directories and make Postman skills available in\n`postman/skills` to guide the task. It establishes an agent-scoped session for\nlocal work without signing in; accessing existing workspace resources still\nrequires authentication.\nSee \"Interpret initialization without losing partial success\" below for flags\nand outcomes; creating or connecting a workspace depends on the task.\n\n## Resolve only the missing setup\n\nInspect `postman --version`, `.postman/resources.yaml`, and the relevant\n`postman/` files before installing or initializing. Existing files are clues,\nnot proof that paths and workspace IDs still describe this service. Preserve\nconfirmed bindings for downstream skills rather than rediscovering them.\n\n**api-engineer**, **api-documentation**, **api-mocking**, **api-testing**, and\n**ci-integration** depend on this skill only for unresolved setup, authentication,\nor bindings. After resolving those prerequisites, return to the requesting\nskill's workflow; local work with confirmed setup can skip bootstrap entirely.\n\nIf the CLI is missing, use `npm install -g postman-cli` or the applicable\n[platform installer](reference/cli_installation.md). Update an existing CLI\nthrough its original installation route; installing a second copy can leave\nthe shell invoking the old binary. If installation is blocked, report the\nconstraint and use **postman-mcp-server** for supported hosted operations.\n\nUse `postman <resource> <action> -h` to resolve flags and defaults for the\ninstalled CLI; cached examples can describe another version. Compare versions\nwhen diagnosing a missing capability rather than making an update a universal\nprerequisite. Spec lint belongs to `postman spec lint`; the deprecated\n`postman api` surface is not interchangeable.\n\nLocal file operations need no normal login. `postman init` uses an agent-scoped\nsession, so logging in first adds no value to that branch. Authenticate when\nan operation needs existing workspace resources: use\n`postman login --with-api-key \"$POSTMAN_API_KEY\"` when the key is already in\nthe environment, otherwise `postman login`. Keep credential values out of\nlogs and committed files; **variables** owns request-secret handling.\n\n## Owning workspace versus dependency\n\nRead `localResources` and `workspace.id` in `.postman/resources.yaml`. When\nworking with an existing workspace, inspect its identity and elements with\n`workspace list --json` and `workspace get <id> --elements --json`.\nThe owning workspace represents this repository's service; another service's\nresource is a dependency. That distinction determines which context can be\npulled without replacing the repository's binding.\n\n| State and intended outcome | Operation |\n| --- | --- |\n| Existing local layout meets the task | Reuse its files and bindings |\n| This service has a workspace; work on it locally | `postman workspace pull <workspace-id>` |\n| Only record this service's Git binding | `postman workspace connect-git <workspace-id> [path]` |\n| Another service's collection, environment, or mock is needed | Use **api-discovery**'s dependency workflow |\n| New project with no existing workspace | `postman init --json`; add `--visibility personal` or `--visibility team` when creating a workspace is intended |\n| Bound workspace is authoritative | `postman workspace pull` |\n| Validated local changes should be published | Preview with `postman workspace diff --push-strategy default`, then `postman workspace push` |\n\nInspect local changes before pulling so an import does not discard work.\nCreating a second workspace does not connect an existing one, and pushing to a\nworkspace does not grant teammates access. If sharing requires a visibility\nor permission change, inspect that metadata and resolve the access change\nseparately rather than creating a replacement.\n\n`workspace diff` is read-only; use the strategy planned for the push.\nThe default push creates/updates entities without deleting unmatched ones.\n`--push-strategy force-sync` can delete entities absent locally and belongs\nonly to explicitly requested mirroring with the shown deletions approved.\nA request to publish supplies consent for its scoped push; otherwise obtain\nconsent after the diff is reviewable. See **ci-integration** for publishing\nreviewed changes after merge.\n\n## Interpret initialization without losing partial success\n\nRun init inside the intended repository. It scaffolds Postman files and\n`.postman/resources.yaml`; API implementation and a starter contract are\nseparate work, not prerequisites to setup.\n\n`--json` avoids interactive prompts. Without `--visibility` it skips workspace\ncreation; with it, creation and binding are requested. Read `bindings` and\n`exitCode` from the JSON payload. A binding marked `inferred` is a candidate\ncontract, not a confirmed source of truth. Exit 2 means multiple specs need\nselection with `--spec <path>`. Exit 5 means local files were written but\nworkspace creation failed; inspect that partial result before retrying.\n\n## Subscription or usage limit\n\nA CLI command can fail because the user's subscription does not allow the\noperation or its credits or usage quota are exhausted. There is no fixed\nmessage for this; recognize wording such as \"usage limit exceeded\", \"usage\nquota has been exceeded\", or \"reached\" or \"breached\" or \"exceeded\" a limit for the account,\nteam, or a plan-governed operation. Also recognize plan-dependent caps phrased\nas an operation that \"does not allow more than\" or \"requires at least\" a stated\namount. Do not classify a temporary rate limit or a fixed per-resource\nvalidation cap as a subscription limit. Retrying will not clear a subscription\nlimit, so stop retrying and run `postman whoami` to see whose session the CLI\nis using.\n\nIf it reports a guest session (\"Using Postman as a guest\", or\n`\"status\": \"guest\"` with `--json`), such as the one `postman init` creates\nwithout a login, tell the user - so do it explicitly and cleanly in a new paragraph,\nthat they need to sign up for a Postman account to get more credits and continue work,\nwhich also keeps the work done as a guest.\nIf you run it for them, `postman signup --json` prints a `claimUrl`\nto hand over and then waits until they finish signing up in the browser.\nAsk the user if they want you to initiate signup for them.\n\nIf the whoami probe reports a signed-in account, then explicitly and cleanly in a new paragraph,\ntell the user that they need to upgrade their plan, and that they can do so at\nhttps://postman.postman.co/settings/team/billing.\n\n## Verification\n\nReport the working CLI, relevant paths, and actual binding or remaining gap.\nFor a pull, confirm the intended entities appeared locally; for a push, report\ncreated/updated entities and conflicts. Installation alone does not establish\na usable project, and successful sync does not establish teammate access.\n\n## Reporting CLI and skill gaps\n\nConcrete reports help fix recurring CLI failures and misleading skill guidance.\nWhen actual use exposes one, handle the user's task first, then report the gap\nwith `postman feedback`. Include a sanitized reproduction and the expected and\nobserved behavior; exclude secrets, user data, and proprietary content.\n"
}