← PostmanCONTENT HISTORY

Update to Postman

Snapshot Oct 24, 2026 · 12:56 UTC · version 0.4.0

Collection source: downloaded plugin package. These snapshots do not have a confirmed matching collection source. Differences in file lists alone do not establish changes to the package.

WHAT CHANGED

Instructions updated for collection-schema-v3

Full description — Now says: Use when writing or debugging local Postman v3 collection and environment YAML, including collection lint failures. Preserves the per-entity files, inherited...

Observed in instructions or declared skills. Runtime behavior has not been tested.

Save Postman and check future changes in Following.

Up to 3 plugins free · no card required.

All fields and original values.

Full description

Before

Sep 30, 2026 · 23:09 UTC

The reference for the git-native v3 collection file format — one YAML file per request/folder/example under postman/collections/, plus postman/environments/. Read before writing, editing, or generating any file in either directory by han...

After

Oct 24, 2026 · 12:56 UTC

Use when writing or debugging local Postman v3 collection and environment YAML, including collection lint failures. Preserves the per-entity files, inherited context, and schema shapes that make API changes reusable and reviewable in Git...

Skill instructions

Before

Sep 30, 2026 · 23:09 UTC

The reference for the git-native v3 collection file format — one YAML file per request/folder/example under postman/collections/, plus postman/environments/. Read before writing, editing, or generating any file in either directory by han...

After

Oct 24, 2026 · 12:56 UTC

Use when writing or debugging local Postman v3 collection and environment YAML, including collection lint failures. Preserves the per-entity files, inherited context, and schema shapes that make API changes reusable and reviewable in Git...

Supporting files

Before

Sep 30, 2026 · 23:09 UTC

[{"relative_path":"reference/environment.md","size_in_bytes":2109},{"relative_path":"reference/other_protocols.md","size_in_bytes":3454}]

After

Oct 24, 2026 · 12:56 UTC

[{"relative_path":"reference/environment.md","size_in_bytes":2109},{"relative_path":"reference/http.md","size_in_bytes":5354},{"relative_path":"reference/other_protocols.md","size_in_bytes":3454}]

Compare saved observations

Download comparison JSON

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,210 +1,49 @@
 ---
 name: collection-schema-v3
-description: The reference for the git-native v3 collection file format — one YAML file per request/folder/example under postman/collections/, plus postman/environments/. Read before writing, editing, or generating any file in either directory by hand, or before debugging a `collection lint` failure. Covers the HTTP request/example/definition schema, environment schema, and the YAML/naming rules that make files parse — GraphQL, gRPC, WebSocket, Socket.IO, MQTT, MCP, and LLM request schemas are non-HTTP protocols and live in reference/other_protocols.md, read only when a collection actually uses one.
+description: Use when writing or debugging local Postman v3 collection and environment YAML, 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".
 ---
 
 # Collection Schema (v3, Git-Native)
 
-## Overview
-
-A v3 collection is a directory tree under `postman/collections/`, one file
-per entity — every request, every folder's metadata, every saved example is
-its own file. There is no single collection.json to open and edit; the
-directory structure itself *is* the collection.
-
-```text
-postman/collections/
-  bookstore api/
-    .resources/
-      definition.yaml (optional)
-      get all books.resources/
-        examples/
-          200 OK.example.yaml
-          400 Bad Request.example.yaml
-          500 Internal Server Error.example.yaml
-    get all books.request.yaml
-    get-book-by-id.request.yaml
-    add new book.request.yaml
-    authentication/
-      .resources/
-        definition.yaml (optional)
-      signup.request.yaml
-      login.request.yaml
-```
-
-- Every folder under `postman/collections/` is a collection; it can contain
-  subfolders and requests.
-- A folder or collection can have a `.resources/` directory — an optional
-  metadata directory for that scope. `.resources/definition.yaml` holds the
-  collection/folder's own metadata; request examples live under
-  `.resources/<request-name>.resources/examples/`.
-- Never place a request file inside a `.resources/` directory — those are
-  metadata-only.
-
-## Definition file (`.resources/definition.yaml`)
-
-Optional metadata for a collection or folder:
-
-- `$kind: "collection"` — required, even for a folder's definition.
-- `name` — optional, defaults to the filesystem folder name.
-- `description` — optional.
-- `variables` — array of `{key, value, description?, disabled?}`. `value`
-  must be a string; `disabled` a boolean.
-- `auth` — a single auth object `{type, credentials: [{key, value}, ...]}`,
-  or an array for multiAuth: `[{id, name, type, credentials, rules?}, ...]`.
-- `scripts` — array of `{type, code, language: "text/javascript"}`. `type`
-  is one of `http:beforeRequest`, `http:afterResponse`,
-  `graphql:beforeQuery`, `graphql:afterResponse`, `grpc:beforeInvoke`,
-  `grpc:onIncomingMessage`, `grpc:afterResponse`.
-- `order` — number, used for folder ordering.
-
-## HTTP request (`*.request.yaml`)
-
-- `$kind: "http-request"` — required.
-- `name` — optional (see naming rules below for when to include it).
-- `order` — number; only used for relative comparison, so space values out
-  (e.g. multiples of 1000) rather than packing them tight — a later
-  insertion between two requests shouldn't force renumbering every sibling.
-- `url` — string, with `{{varName}}` variable syntax.
-- `method` — `GET|POST|PUT|DELETE|PATCH|HEAD|OPTIONS`.
-- `headers` — array of `{key, value, description?, disabled?}`.
-- `queryParams` — array of `{key, value, description?, disabled?}`.
-- `pathVariables` — array of `{key, value, description?}`.
-- `body` — `{type, content}`; `type` required whenever `body` is present.
-  - Types: `json`, `formdata`, `urlencoded`, `text`, `xml`, `html`,
-    `javascript`, `file`, `none`.
-  - `json`/`text`/`xml`/`html`/`javascript`: `content` is a string.
-  - `formdata`: `content` is an array of
-    `{key, type: "text"|"file", value or src, contentType?, description?}`.
-  - `urlencoded`: `content` is an array of `{key, value, description?}`.
-- `auth` — `{type, credentials}`.
-- `settings` —
-  `{protocolVersion?, strictSSL?, followRedirects?, maxRedirects?, disabledSystemHeaders?}`.
-- `scripts` — array of `{type: "beforeRequest"|"afterResponse", code, language: "text/javascript"}`.
-- `examples` — optional, a relative path to the examples directory, e.g.
-  `./.resources/<request-name>.resources/examples/`.
-
-## HTTP example (`*.example.yaml`)
-
-- `$kind: "http-example"` — required.
-- `name` — optional.
-- `request: {url, method}`.
-- `response: {statusCode, statusText, headers: [{key, value}], body: {type, content}}`.
-- `order` — optional.
-
-Saved examples are what `collection ai-readiness` checks for — a request
-with no examples scores worse for agent consumption even if perfectly
-valid structurally.
-
-## Environments (`postman/environments/*.environment.yaml`)
-
-Environment files are v3 YAML but are not collection entities: they do not use
-`$kind`. Before creating or editing one by hand, read
-[reference/environment.md](reference/environment.md) for the schema, secret
-handling, CLI-first edit commands, and a linted example.
-
-## YAML rules
-
-Invalid YAML breaks parsing silently in confusing ways — when in doubt,
-single-quote it:
-
-1. Single-quote any value containing `{{variables}}`:
-   `url: '{{base_url}}/users'` — never leave it unquoted.
-2. Single-quote values containing `: # & * ! [ ] { } > |`, e.g.
-   `name: 'Health check: v2'`.
-3. Multi-line content (JSON bodies, scripts, queries) uses a `|-` block
-   scalar:
-   ```yaml
-   body:
-     type: json
-     content: |-
-       {
-         "name": "example"
-       }
-   ```
-4. Quote strings that resemble booleans/numbers when a string is intended:
-   `value: "true"`, `value: "123"`.
-5. `order` must be a bare number, never quoted: `order: 1000`.
-6. Single-quote file paths and use forward slashes only:
-   `examples: './.resources/name.resources/examples'`.
-
-## Naming rules
-
-- `<request-name>` (the filename stem before `.request.yaml`) must not
-  contain `/ \ : * ? " < > |` — sanitize to `-`.
-- Include `name` in the file only when it differs from `<request-name>`
-  (e.g. `name: 'Health/check'` inside `Health-check.request.yaml`, since the
-  filename itself can't hold the `/`).
-- Filenames must be unique, case-insensitively, per directory.
-
-## Worked example: "bookstore api"
-
-`postman/collections/bookstore api/get all books.request.yaml`
-```yaml
-$kind: http-request
-method: GET
-url: '{{base_url}}/books'
-order: 1000
-```
-
-`postman/collections/bookstore api/get-book-by-id.request.yaml`
-```yaml
-$kind: http-request
-name: 'get book by :id'
-method: GET
-url: '{{base_url}}/books/:id'
-order: 2000
-pathVariables:
-  - key: id
-    value: '1'
-```
-
-`postman/collections/bookstore api/add new book.request.yaml`
-```yaml
-$kind: http-request
-method: POST
-url: '{{base_url}}/books'
-order: 3000
-headers:
-  - key: Content-Type
-    value: application/json
-body:
-  type: json
-  content: |-
-    {
-      "title": "Example Book",
-      "author": "Jane Doe"
-    }
-```
-
-`postman/collections/bookstore api/.resources/definition.yaml`
-```yaml
-$kind: collection
-name: Bookstore API
-variables:
-  - key: base_url
-    value: 'https://api.bookstore.com/v1'
-```
-
-## Critical Rules
-
-1. **Every entity is its own file — there's no single collection.json to
-   open.** A request, its parent folder's metadata, and its saved examples
-   are three separate files, not sections of one document.
-2. **Unquoted `{{variables}}` or special characters are the most common way
-   a hand-written file fails to parse.** Single-quote per the YAML rules
-   above rather than debugging a cryptic lint error after the fact.
-3. **`order` is relative, not an index.** Don't renumber every sibling file
-   to insert one request — leave headroom (spacing of 1000) from the start.
-4. **This file covers HTTP only.** A collection using GraphQL, gRPC,
-   WebSocket, Socket.IO, MQTT, MCP, or LLM requests needs
-   [reference/other_protocols.md](reference/other_protocols.md) — don't
-   guess those schemas from the HTTP shape above, they diverge in real ways
-   (e.g. gRPC's `methodDescriptor`, LLM's `userPrompts`/`systemPrompts`).
-
-## Reference
-
-- [Other request protocols](reference/other_protocols.md) — GraphQL, gRPC,
-  WebSocket, Socket.IO, MQTT, MCP, and LLM request schemas.
-- [Environment schema](reference/environment.md) — v3 environment filenames,
-  fields, variable types, safe editing commands, and validation.
+A v3 collection is a directory of independently editable entities. A change to
+one request, example, or assertion can be reviewed in a PR beside the code it
+checks, without regenerating a single large collection export.
+
+1. Edit the entity that owns the change. Top-level directories under
+   `postman/collections/` are collections; nested folders organize requests.
+   Requests live in `*.request.yaml`, scope metadata in
+   `.resources/definition.yaml`, and saved responses in
+   `.resources/<request-name>.resources/examples/*.example.yaml`.
+   `.resources/` holds metadata and examples, not runnable request files.
+2. Preserve inherited auth, variables, and scripts when changing a request.
+   Collection/folder definitions supply shared context; copying every inherited
+   field into each request creates competing values and noisy future edits.
+   See **variables** when deciding the scope of a value or secret reference.
+3. Use [HTTP field shapes and examples](reference/http.md) when authoring
+   request, example, or definition files. For other protocols, read
+   [their schemas](reference/other_protocols.md); HTTP's URL/body/script shape
+   cannot be assumed for gRPC, WebSocket, MCP, or LLM requests.
+   [Environment files](reference/environment.md) have their own schema and
+   do not use the collection entity's `$kind` discriminator.
+4. Preserve types at the YAML boundary. Quote `{{variables}}` and strings that
+   resemble booleans or numbers; JSON bodies are string content, best expressed
+   with block scalars. A syntactically valid YAML object can still be the wrong
+   request body shape. The HTTP reference gives the exact fields.
+5. Keep edits local to the intended entity. `order` is a numeric relative
+   ordering, so spaced values allow insertion without renumbering siblings.
+   Keep filenames portable and unique case-insensitively; a display `name`
+   can preserve characters that cannot appear in a filename. Renaming a request
+   also requires checking its examples path.
+6. Save examples for behavior consumers need to understand or simulate.
+   Their schemas feed **api-documentation**, **api-mocking**, and
+   **ai-readiness**; structural validity alone does not make an example
+   accurate or useful. Assertions derived from the contract belong with the
+   request through **api-testing**.
+
+## Verification
+
+Run `postman collection lint <collection-path>` for collection changes and
+`postman environment lint <path>` for environment changes. Then inspect the
+diff for unintended scope changes; when execution is appropriate, run the
+changed request through its collection to check inherited context. Report
+structural validation separately from behavior verified against a target.
Full technical diff · 3 changed fields

changed /description

BEFORE
"The reference for the git-native v3 collection file format — one YAML file per request/folder/example under postman/collections/, plus postman/environments/. Read before writing, editing, or generating any file in either directory by hand, or before debugging a `collection lint` failure. Covers the HTTP request/example/definition schema, environment schema, and the YAML/naming rules that make files parse — GraphQL, gRPC, WebSocket, Socket.IO, MQTT, MCP, and LLM request schemas are non-HTTP protocols and live in reference/other_protocols.md, read only when a collection actually uses one."
AFTER
"Use when writing or debugging local Postman v3 collection and environment YAML, 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\"."

changed /included_files

BEFORE
[
  {
    "relative_path": "reference/environment.md",
    "size_in_bytes": 2109
  },
  {
    "relative_path": "reference/other_protocols.md",
    "size_in_bytes": 3454
  }
]
AFTER
[
  {
    "relative_path": "reference/environment.md",
    "size_in_bytes": 2109
  },
  {
    "relative_path": "reference/http.md",
    "size_in_bytes": 5354
  },
  {
    "relative_path": "reference/other_protocols.md",
    "size_in_bytes": 3454
  }
]

changed /skill_md_contents

BEFORE
"---\nname: collection-schema-v3\ndescription: The reference for the git-native v3 collection file format — one YAML file per request/folder/example under postman/collections/, plus postman/environments/. Read before writing, editing, or generating any file in either directory by hand, or before debugging a `collection lint` failure. Covers the HTTP request/example/definition schema, environment schema, and the YAML/naming rules that make files parse — GraphQL, gRPC, WebSocket, Socket.IO, MQTT, MCP, and LLM request schemas are non-HTTP protocols and live in reference/other_protocols.md, read only when a collection actually uses one.\n---\n\n# Collection Schema (v3, Git-Native)\n\n## Overview\n\nA v3 collection is a directory tree under `postman/collections/`, one file\nper entity — every request, every folder's metadata, every saved example is\nits own file. There is no single collection.json to open and edit; the\ndirectory structure itself *is* the collection.\n\n```text\npostman/collections/\n  bookstore api/\n    .resources/\n      definition.yaml (optional)\n      get all books.resources/\n        examples/\n          200 OK.example.yaml\n          400 Bad Request.example.yaml\n          500 Internal Server Error.example.yaml\n    get all books.request.yaml\n    get-book-by-id.request.yaml\n    add new book.request.yaml\n    authentication/\n      .resources/\n        definition.yaml (optional)\n      signup.request.yaml\n      login.request.yaml\n```\n\n- Every folder under `postman/collections/` is a collection; it can contain\n  subfolders and requests.\n- A folder or collection can have a `.resources/` directory — an optional\n  metadata directory for that scope. `.resources/definition.yaml` holds the\n  collection/folder's own metadata; request examples live under\n  `.resources/<request-name>.resources/examples/`.\n- Never place a request file inside a `.resources/` directory — those are\n  metadata-only.\n\n## Definition file (`.resources/definition.yaml`)\n\nOptional metadata for a collection or folder:\n\n- `$kind: \"collection\"` — required, even for a folder's definition.\n- `name` — optional, defaults to the filesystem folder name.\n- `description` — optional.\n- `variables` — array of `{key, value, description?, disabled?}`. `value`\n  must be a string; `disabled` a boolean.\n- `auth` — a single auth object `{type, credentials: [{key, value}, ...]}`,\n  or an array for multiAuth: `[{id, name, type, credentials, rules?}, ...]`.\n- `scripts` — array of `{type, code, language: \"text/javascript\"}`. `type`\n  is one of `http:beforeRequest`, `http:afterResponse`,\n  `graphql:beforeQuery`, `graphql:afterResponse`, `grpc:beforeInvoke`,\n  `grpc:onIncomingMessage`, `grpc:afterResponse`.\n- `order` — number, used for folder ordering.\n\n## HTTP request (`*.request.yaml`)\n\n- `$kind: \"http-request\"` — required.\n- `name` — optional (see naming rules below for when to include it).\n- `order` — number; only used for relative comparison, so space values out\n  (e.g. multiples of 1000) rather than packing them tight — a later\n  insertion between two requests shouldn't force renumbering every sibling.\n- `url` — string, with `{{varName}}` variable syntax.\n- `method` — `GET|POST|PUT|DELETE|PATCH|HEAD|OPTIONS`.\n- `headers` — array of `{key, value, description?, disabled?}`.\n- `queryParams` — array of `{key, value, description?, disabled?}`.\n- `pathVariables` — array of `{key, value, description?}`.\n- `body` — `{type, content}`; `type` required whenever `body` is present.\n  - Types: `json`, `formdata`, `urlencoded`, `text`, `xml`, `html`,\n    `javascript`, `file`, `none`.\n  - `json`/`text`/`xml`/`html`/`javascript`: `content` is a string.\n  - `formdata`: `content` is an array of\n    `{key, type: \"text\"|\"file\", value or src, contentType?, description?}`.\n  - `urlencoded`: `content` is an array of `{key, value, description?}`.\n- `auth` — `{type, credentials}`.\n- `settings` —\n  `{protocolVersion?, strictSSL?, followRedirects?, maxRedirects?, disabledSystemHeaders?}`.\n- `scripts` — array of `{type: \"beforeRequest\"|\"afterResponse\", code, language: \"text/javascript\"}`.\n- `examples` — optional, a relative path to the examples directory, e.g.\n  `./.resources/<request-name>.resources/examples/`.\n\n## HTTP example (`*.example.yaml`)\n\n- `$kind: \"http-example\"` — required.\n- `name` — optional.\n- `request: {url, method}`.\n- `response: {statusCode, statusText, headers: [{key, value}], body: {type, content}}`.\n- `order` — optional.\n\nSaved examples are what `collection ai-readiness` checks for — a request\nwith no examples scores worse for agent consumption even if perfectly\nvalid structurally.\n\n## Environments (`postman/environments/*.environment.yaml`)\n\nEnvironment files are v3 YAML but are not collection entities: they do not use\n`$kind`. Before creating or editing one by hand, read\n[reference/environment.md](reference/environment.md) for the schema, secret\nhandling, CLI-first edit commands, and a linted example.\n\n## YAML rules\n\nInvalid YAML breaks parsing silently in confusing ways — when in doubt,\nsingle-quote it:\n\n1. Single-quote any value containing `{{variables}}`:\n   `url: '{{base_url}}/users'` — never leave it unquoted.\n2. Single-quote values containing `: # & * ! [ ] { } > |`, e.g.\n   `name: 'Health check: v2'`.\n3. Multi-line content (JSON bodies, scripts, queries) uses a `|-` block\n   scalar:\n   ```yaml\n   body:\n     type: json\n     content: |-\n       {\n         \"name\": \"example\"\n       }\n   ```\n4. Quote strings that resemble booleans/numbers when a string is intended:\n   `value: \"true\"`, `value: \"123\"`.\n5. `order` must be a bare number, never quoted: `order: 1000`.\n6. Single-quote file paths and use forward slashes only:\n   `examples: './.resources/name.resources/examples'`.\n\n## Naming rules\n\n- `<request-name>` (the filename stem before `.request.yaml`) must not\n  contain `/ \\ : * ? \" < > |` — sanitize to `-`.\n- Include `name` in the file only when it differs from `<request-name>`\n  (e.g. `name: 'Health/check'` inside `Health-check.request.yaml`, since the\n  filename itself can't hold the `/`).\n- Filenames must be unique, case-insensitively, per directory.\n\n## Worked example: \"bookstore api\"\n\n`postman/collections/bookstore api/get all books.request.yaml`\n```yaml\n$kind: http-request\nmethod: GET\nurl: '{{base_url}}/books'\norder: 1000\n```\n\n`postman/collections/bookstore api/get-book-by-id.request.yaml`\n```yaml\n$kind: http-request\nname: 'get book by :id'\nmethod: GET\nurl: '{{base_url}}/books/:id'\norder: 2000\npathVariables:\n  - key: id\n    value: '1'\n```\n\n`postman/collections/bookstore api/add new book.request.yaml`\n```yaml\n$kind: http-request\nmethod: POST\nurl: '{{base_url}}/books'\norder: 3000\nheaders:\n  - key: Content-Type\n    value: application/json\nbody:\n  type: json\n  content: |-\n    {\n      \"title\": \"Example Book\",\n      \"author\": \"Jane Doe\"\n    }\n```\n\n`postman/collections/bookstore api/.resources/definition.yaml`\n```yaml\n$kind: collection\nname: Bookstore API\nvariables:\n  - key: base_url\n    value: 'https://api.bookstore.com/v1'\n```\n\n## Critical Rules\n\n1. **Every entity is its own file — there's no single collection.json to\n   open.** A request, its parent folder's metadata, and its saved examples\n   are three separate files, not sections of one document.\n2. **Unquoted `{{variables}}` or special characters are the most common way\n   a hand-written file fails to parse.** Single-quote per the YAML rules\n   above rather than debugging a cryptic lint error after the fact.\n3. **`order` is relative, not an index.** Don't renumber every sibling file\n   to insert one request — leave headroom (spacing of 1000) from the start.\n4. **This file covers HTTP only.** A collection using GraphQL, gRPC,\n   WebSocket, Socket.IO, MQTT, MCP, or LLM requests needs\n   [reference/other_protocols.md](reference/other_protocols.md) — don't\n   guess those schemas from the HTTP shape above, they diverge in real ways\n   (e.g. gRPC's `methodDescriptor`, LLM's `userPrompts`/`systemPrompts`).\n\n## Reference\n\n- [Other request protocols](reference/other_protocols.md) — GraphQL, gRPC,\n  WebSocket, Socket.IO, MQTT, MCP, and LLM request schemas.\n- [Environment schema](reference/environment.md) — v3 environment filenames,\n  fields, variable types, safe editing commands, and validation.\n"
AFTER
"---\nname: collection-schema-v3\ndescription: Use when writing or debugging local Postman v3 collection and environment YAML, 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. Use [HTTP field shapes and examples](reference/http.md) when authoring\n   request, example, or definition files. For other protocols, read\n   [their schemas](reference/other_protocols.md); HTTP's URL/body/script shape\n   cannot be assumed for gRPC, WebSocket, MCP, or LLM requests.\n   [Environment files](reference/environment.md) have their own schema and\n   do not use the collection entity's `$kind` discriminator.\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. Then inspect the\ndiff for unintended scope changes; when execution is appropriate, run the\nchanged request through its collection to check inherited context. Report\nstructural validation separately from behavior verified against a target.\n"
Full snapshot data
{
  "description": "Use when writing or debugging local Postman v3 collection and environment YAML, 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": 2109
    },
    {
      "relative_path": "reference/http.md",
      "size_in_bytes": 5354
    },
    {
      "relative_path": "reference/other_protocols.md",
      "size_in_bytes": 3454
    }
  ],
  "name": "collection-schema-v3",
  "skill_md_contents": "---\nname: collection-schema-v3\ndescription: Use when writing or debugging local Postman v3 collection and environment YAML, 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. Use [HTTP field shapes and examples](reference/http.md) when authoring\n   request, example, or definition files. For other protocols, read\n   [their schemas](reference/other_protocols.md); HTTP's URL/body/script shape\n   cannot be assumed for gRPC, WebSocket, MCP, or LLM requests.\n   [Environment files](reference/environment.md) have their own schema and\n   do not use the collection entity's `$kind` discriminator.\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. Then inspect the\ndiff for unintended scope changes; when execution is appropriate, run the\nchanged request through its collection to check inherited context. Report\nstructural validation separately from behavior verified against a target.\n"
}

SHA-256 of public snapshot: f6aa3a5992174e641c4def1dec34be80125928059e39767092bde14e5b5f847e