Update to Postman

{
  "description": "Use when defining or improving an API contract, generating documentation from a collection or OpenAPI spec, publishing API docs, or sharing a documentation link. Makes auth, inputs, responses, and examples reusable by callers, tests, and mocks. Use for requests such as \"publish API docs\".",
  "included_files": [
    {
      "relative_path": "reference/rest-api-best-practices.md",
      "size_in_bytes": 2995
    }
  ],
  "name": "api-documentation",
  "skill_md_contents": "---\nname: api-documentation\ndescription: Use when defining or improving an API contract, generating documentation from a collection or OpenAPI spec, publishing API docs, or sharing a documentation link. Makes auth, inputs, responses, and examples reusable by callers, tests, and mocks. Use for requests such as \"publish API docs\".\n---\n\n# API Documentation\n\nA maintained contract gives callers enough information to integrate without\nreading the implementation. Keeping descriptions and examples beside the API\nartifacts lets the same knowledge support documentation, tests, and mocks,\nwith changes reviewable alongside code.\n\n1. Start from the existing source of truth. An OpenAPI spec describes the\n   interface for tooling; a Postman collection adds runnable requests,\n   examples, and assertions. Maintain both when both uses matter, with an\n   explicit direction of generation or synchronization so they do not become\n   competing definitions.\n2. When the spec is authoritative, reuse its operations with\n   `postman spec generate collection <spec-path-or-id> -n \"<collection-name>\"`.\n   Inspect the generated result before replacing an existing collection:\n   maintained scripts and examples carry knowledge beyond endpoint shapes.\n3. Describe what changes a caller's decision: required versus optional inputs,\n   auth and scopes, response guarantees, pagination, retryable failures, and\n   side effects. Derive guarantees from the agreed contract or verified\n   behavior; label unresolved design choices instead of inventing them.\n   Use [REST design guidance](reference/rest-api-best-practices.md) when a\n   design choice affects usability or compatibility, not to redesign an\n   unrelated interface while filling a documentation gap.\n4. Save examples that clarify consequential cases, including relevant errors.\n   Examples become inputs for mocks as well as explanations for readers;\n   a success-only example can hide the failure path callers must handle.\n   Use **collection-schema-v3** for local collection edits and **variables**\n   to keep credentials out of reusable requests and examples.\n5. Choose delivery by audience. Local artifacts support Git review;\n   publishing to the bound workspace makes them available to teammates with\n   access. A workspace push does not itself publish a\n   public docs page or change permissions. For a public documentation link,\n   use **postman-mcp-server**'s documentation workflow and the available\n   publishing tool; establish the intended audience before public exposure.\n\n## Verification\n\nCheck that the edited artifact parses and its examples agree with the\ncontract. For a publication, inspect the resulting page and report its actual\nlink and visibility; a successful upload alone does not show readers usable\ndocumentation. State any behavior that remains undocumented or unverified.\n"
}