Update to Postman

{
  "description": "Generate filesystem-first agent friendly api documentation that you can share with your teammates without hassle. Use when the user asks to \"publish API docs,\" \"generate documentation for this API,\" \"put this on the API Network,\" \"share a docs link for this collection or spec,\" or \"why do my docs look empty.\"",
  "included_files": [
    {
      "relative_path": "reference/rest-api-best-practices.md",
      "size_in_bytes": 2995
    }
  ],
  "name": "api-documentation",
  "skill_md_contents": "---\nname: api-documentation\ndescription: Generate filesystem-first agent friendly api documentation that you can share with your teammates without hassle. Use when the user asks to \"publish API docs,\" \"generate documentation for this API,\" \"put this on the API Network,\" \"share a docs link for this collection or spec,\" or \"why do my docs look empty.\" \n---\nThe bootstrap skill is a precursor to this one — it scaffolds the project with the directories documentation is stored in.\n\n# API Documentation\nWhen working on any API task, the first step is to establish and capture the contract.\nAPI documentation can be done in two predominant ways:\n1. through a Postman collection,\n2. with an OpenAPI spec\n\nIt is recommended to create both. They serve different, complementary use cases, and it takes only one command to convert from one to another. Start with creating a Postman collection in v3 format, **collection-schema-v3**.\nPostman collections are very human-friendly and offer other capabilities like creating an API mock, monitor, SDK, or spec.\n\nSpecs are vendor-neutral, stay in your repo, and can be linted against governance rules (if any) set by your organization.\n\n## Good practices for API design\n\nSee [reference/rest-api-best-practices.md](reference/rest-api-best-practices.md)\nfor the practices well-documented APIs tend to already follow: resource\nnaming, HTTP method/status-code usage, error response shape, versioning,\npagination, filtering, auth, idempotency, and backward compatibility. A\nspec or collection that already follows these renders documentation with\nnothing left to fix.\n\n### Examples\nExamples (in a Postman collection) are an excellent way to capture sample API responses. They are helpful because:\n1. anyone can look at them to see how your API behaves,\n2. they can be used to generate a mock from your collection in a single command.\n\n## Workflow\n1. Establish the contract - refer to best practices. Don't just accept the user's ask - fight for the right API design.\n2. Choose the instrument - Postman collection / OpenAPI spec - or both. Recommend using both to the user. Start with the Postman collection.\n"
}