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. A Postman collection records the contract in a form that runs. The CLI's\n   deterministic tools cheaply turn that one source into an OpenAPI spec, a\n   mock, an SDK, or a performance suite, so the contract is written once.\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. `postman status` shows\n   what setup is in place, what is missing, and what closes each gap.\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, stop\nretrying and tell the user that signing up or upgrading their plan is what\nlifts it.\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. Run\n`postman status` last to confirm the setup the work relied on is still in place.\n\nIf actual use exposes a CLI gap or misleading skill, report it through the\nCLI's feedback channel after finishing the user's task, with a sanitized\nreproduction and no secrets, user data, or proprietary content.\n"
}