Update to Postman

{
  "name": "api-engineer",
  "description": "Default entry point for API engineering work — designing, implementing, mocking, testing, monitoring, documenting, or deploying an API.",
  "included_files": [],
  "skill_md_contents": "---\nname: api-engineer\ndescription: Default entry point for API engineering work — designing, implementing, mocking, testing, monitoring, documenting, or deploying an API.\n---\n\n# API Engineer\n\n## Foundations\n1. Contract comes first. Establish and document the contract before starting implementation.\n2. A Postman collection and/or an OpenAPI spec is a very good option to capture the API contract - see **api-documentation**.\n3. Always validate the change against the contract you started with. Running a Postman collection is a very easy way to do this - see **api-testing**.\n4. Always propose next steps. Example: contract -> implementation -> testing -> pushing to cloud -> sharing with others.\n5. Don't jump straight into implementation. Consider whether you should first set up a mock to unblock the API consumer even before implementation is done - see **api-mocking**. This also helps when the user doesn't want the backend fully functional yet and just wants the responses mocked.\n6. Don't push to the cloud workspace (`postman workspace push`) without user consent. The recommended way to push to the cloud is a CI step on PR merge - see **ci-integration**.\n7. For high-quality API search results, use **api-discovery**.\n8. No is an acceptable answer. Asked whether to do something, invited to add scope, or shown an approach, reply with your real judgment.\n9. Prefer filesystem-first Postman workflows. For an existing cloud workspace,\n   `postman workspace pull <id>` connects it and materializes its collections,\n   environments, and specs locally. When no cloud workspace exists, `postman\n   init --no-cloud` initializes the local structure. Work against those files,\n   validate them, and push only with user consent; sharing an already-bound\n   workspace means `workspace push`, not creating a duplicate. See\n   **bootstrap** for the lifecycle decision table.\n10. When actual use exposes a concrete Postman CLI gap or a misleading skill, handle the user's task first — then use `postman feedback` to report the gaps/bugs. Exclude secrets, user data, and proprietary content\n\n## Dos\n1. Prove it works - validate the task against the contract. See **api-testing**.\n2. Just do it - never block on the human. When tempted to ask \"should I do X?\" on reversible work, proceed, present the result, and let the human course-correct.\n3. Fight for good API design. See **api-documentation**.\n"
}