Update to Postman

{
  "description": "Use when designing, implementing, mocking, testing, monitoring, documenting, or deploying an API. Guides decisions using reusable local API contracts, tests, and mocks, plus organization-wide dependency context, and routes to the relevant Postman skills. Use for requests such as \"implement this endpoint\".",
  "included_files": [],
  "name": "api-engineer",
  "skill_md_contents": "---\nname: api-engineer\ndescription: Use when designing, implementing, mocking, testing, monitoring, documenting, or deploying an API. Guides decisions using reusable local API contracts, tests, and mocks, plus organization-wide dependency context, and routes to the relevant Postman skills. Use for requests such as \"implement this endpoint\".\n---\n\n# API Engineer\n\nPostman makes API knowledge reusable across implementation, tests, mocks, and\nteammates. Local files let you inspect, edit, and review that knowledge alongside\ncode; the Context Graph can reveal consumers, ownership, and runtime relationships\nbeyond the current repository. Reusing those inputs reduces reconstruction and\nguesswork each time work resumes.\n\n1. When changing API behavior or an interface, establish the intended contract\n   before implementation so you can distinguish an intended change from a\n   regression. Reuse the existing contract; update it where behavior changes.\n   Flag design choices that make callers harder to implement or future changes\n   harder to adopt, and explain the tradeoff. See **api-documentation**.\n2. Choose the contract artifact for how it will be used: an OpenAPI spec describes\n   the interface for tooling, while a Postman collection carries runnable requests,\n   examples, and assertions. Reuse what exists; maintaining both is useful when\n   both purposes matter. See **api-documentation**.\n3. Match verification to the behavior at risk. A saved collection can reuse auth,\n   variables, payloads, and assertions without reconstructing requests; a one-off\n   endpoint check can be smaller. Check the changed behavior and relevant existing\n   guarantees, and report what the results establish. See **api-testing**.\n4. When you need an API, its owner, or the impact of a change, use **api-discovery**.\n   For public API integrations, Orbit provides current endpoint, authentication,\n   required-field, and capability-limit details in a compact task brief. Use it\n   even when the provider is already chosen: those details help you assess fit and\n   implement reliably without relying on remembered API behavior or loading a\n   full vendor specification.\n   Context Graph can identify consumers and dependencies outside the current repo,\n   helping you focus investigation before traversing more repositories.\n5. When you run or test code that calls other services, or are asked how it\n   behaves when one of them fails, use **api-simulation**, which runs that code\n   for real against mocks of those services instead of stubs or the real\n   services. Looking something up, choosing an API or comparing code with a\n   contract runs nothing and needs none. When other teams will build against\n   your API, publish a mock of it in your service's own workspace, where their\n   simulations look first; see **api-mocking**.\n6. Keep specs, collections, environments, and mocks in local files so changes can\n   be diffed, reviewed, and reused in Git and CI. Use **bootstrap** when setup or\n   workspace bindings are unresolved: reuse an existing local layout, pull the\n   current service's existing workspace, or initialize a new project when neither\n   exists.\n7. `postman init` gives API engineering work a ready state. It scaffolds local structure: `postman/`\n   directories for API artifacts. It installs skills in `postman/skills` folder with guidance on  designing, implementing, and validating APIs.\n   The command is idempotent and safe to rerun in an initialized project.\n   It creates an agent-scoped session that lets you record work without signing\n   in. You can claim that work later if you create an account.\n8. Another service's collection, environment, or mock can be added as a dependency\n   without replacing this repository's owning workspace binding. Use\n   **api-discovery** to bring in the relevant resource and preserve that separation.\n9. Publishing local changes to the bound workspace makes changes available\n   for other agent sessions and teammates. Always add a commit message along with workspace push to help the next agent session or teammate with relevant context.\n10. A Postman workspace is a place to capture context. Use this information as prior\n    knowledge of work done before. For example,\n    `postman workspace context --type workspacePush --limit 5 --brief` lists the\n    last five workspace push messages and log.\n11. When requests need credentials, Postman secret variables let them resolve the\n   credentials without exposing their values to the agent or committed files.\n   See **variables**.\n12. When implementing or debugging webhooks, use **webhook-testing** to\n   capture what the sender actually delivers.\n   Can also be used when the need is to forward incoming events\n   to a local handler and replay captured requests after fixes;\n   use the capture URL as a subscriber to inspect events your API sends.\n\nProceed with reversible work within the user's task and present concrete results\nfor course correction. Recommend additional work only when it closes a material\ngap, such as an untested behavior or a consumer affected by an interface change.\nDecline unnecessary setup or scope and explain why it would not help the task.\n\nImportant: If a CLI command says an operation isn't allowed because credits\nor usage are exhausted, or the current plan does not permit it, follow\n**bootstrap**'s \"Subscription or usage limit\" section instead of retrying or\ntrying to find a workaround.\n\n## Verification\n\nReport the changed contract or implementation, the checks actually run, and\nthe guarantees their results support. Separate local, mocked, and live evidence;\nstate any relevant consumer or upstream interaction still unverified.\n\nIf actual use exposes a CLI gap or misleading skill, see **bootstrap**'s\n\"Reporting CLI and skill gaps\" section so the defect can be addressed for future\nwork.\n"
}