Update to Postman

{
  "description": "Use when writing or debugging local Postman v3 collection, environment or globals files, including collection lint failures. Preserves the per-entity files, inherited context, and schema shapes that make API changes reusable and reviewable in Git. Use for requests such as \"fix this request YAML\".",
  "included_files": [
    {
      "relative_path": "reference/environment.md",
      "size_in_bytes": 2232
    },
    {
      "relative_path": "reference/globals.md",
      "size_in_bytes": 1213
    },
    {
      "relative_path": "reference/http.md",
      "size_in_bytes": 9193
    },
    {
      "relative_path": "reference/other_protocols.md",
      "size_in_bytes": 7236
    }
  ],
  "name": "collection-schema-v3",
  "skill_md_contents": "---\nname: collection-schema-v3\ndescription: Use when writing or debugging local Postman v3 collection, environment or globals files, including collection lint failures. Preserves the per-entity files, inherited context, and schema shapes that make API changes reusable and reviewable in Git. Use for requests such as \"fix this request YAML\".\n---\n\n# Collection Schema (v3, Git-Native)\n\nA v3 collection is a directory of independently editable entities. A change to\none request, example, or assertion can be reviewed in a PR beside the code it\nchecks, without regenerating a single large collection export.\n\n1. Edit the entity that owns the change. Top-level directories under\n   `postman/collections/` are collections; nested folders organize requests.\n   Requests live in `*.request.yaml`, scope metadata in\n   `.resources/definition.yaml`, and saved responses in\n   `.resources/<request-name>.resources/examples/*.example.yaml`.\n   `.resources/` holds metadata and examples, not runnable request files.\n2. Preserve inherited auth, variables, and scripts when changing a request.\n   Collection/folder definitions supply shared context; copying every inherited\n   field into each request creates competing values and noisy future edits.\n   See **variables** when deciding the scope of a value or secret reference.\n3. Consult the reference section for the entity being changed:\n   [HTTP requests, examples, and definitions](reference/http.md),\n   [environment files](reference/environment.md), or\n   [other protocols](reference/other_protocols.md).\n   Protocols have different URL, body, script, and settings shapes; an HTTP\n   field is not necessarily valid on another request kind.\n   For globals files, use the [globals reference](reference/globals.md).\n   Dataset YAML belongs to **datasets**; mocks belong to **api-mocking**.\n4. Preserve types at the YAML boundary. Quote `{{variables}}` and strings that\n   resemble booleans or numbers; JSON bodies are string content, best expressed\n   with block scalars. A syntactically valid YAML object can still be the wrong\n   request body shape. The HTTP reference gives the exact fields.\n5. Keep edits local to the intended entity. `order` is a numeric relative\n   ordering, so spaced values allow insertion without renumbering siblings.\n   Keep filenames portable and unique case-insensitively; a display `name`\n   can preserve characters that cannot appear in a filename. Renaming a request\n   also requires checking its examples path.\n6. Save examples for behavior consumers need to understand or simulate.\n   Their schemas feed **api-documentation**, **api-mocking**, and\n   **ai-readiness**; structural validity alone does not make an example\n   accurate or useful. Assertions derived from the contract belong with the\n   request through **api-testing**.\n\n## Verification\n\nRun `postman collection lint <collection-path>` for collection changes and\n`postman environment lint <path>` for environment changes. Review warnings as\nwell as errors: an ignored field can change behavior even when parsing succeeds.\nUse `postman workspace lint` when checking relationships across entities or\nworkspace manifest mappings.\n\nInspect the diff for unintended scope changes. When execution is appropriate,\nrun the changed request through its collection to check inherited context.\nFor script changes, check that the changed script executed and produced its\nintended effect; compare assertion counts with the assertions expected for that\nrun. A setup script may intentionally have none, and unrelated passing assertions\ndo not prove the changed script worked. Report structural validation separately\nfrom behavior verified against a target.\n"
}