Update to Postman

{
  "name": "performance-testing",
  "description": "Load-tests a collection with concurrent virtual users, a chosen load profile, and pass/fail thresholds on latency or error rate — run locally or on Postman's cloud runners. Use when the user asks to \"load test this API,\" \"run a performance test,\" \"check how this holds up under load,\" or \"benchmark this collection.\" Covers `postman performance run`. This generates real traffic against a real target — confirm the target and scale before running, the same way any action with effects outside this session gets confirmed.",
  "included_files": [],
  "skill_md_contents": "---\nname: performance-testing\ndescription: Load-tests a collection with concurrent virtual users, a chosen load profile, and pass/fail thresholds on latency or error rate — run locally or on Postman's cloud runners. Use when the user asks to \"load test this API,\" \"run a performance test,\" \"check how this holds up under load,\" or \"benchmark this collection.\" Covers `postman performance run`. This generates real traffic against a real target — confirm the target and scale before running, the same way any action with effects outside this session gets confirmed.\n---\n\n# Performance Testing\n\n## Overview\n\n`performance run <collectionId>` is not `collection run` with more\niterations — it's a dedicated load-test mode: many virtual users hitting the\ncollection concurrently for a set duration, shaped by a load profile, scored\nagainst thresholds you define, on infrastructure you choose. The collection\nunder test is authored the normal way — see the `collection-schema-v3` skill\nif it needs edits before the load test is meaningful (e.g. an assertion\nthat would fail every VU's request identically).\n\n## Core knowledge\n\n- **Load profile is what you're actually testing.** `fixed` holds steady\n  concurrency (does this hold up at N users, sustained); `ramp-up` increases\n  gradually (where does it start to degrade); `spike` bursts suddenly (does\n  a sudden surge break it); `peak` sustains near-maximum load (does it\n  survive staying there). Pick based on the failure mode being probed, not\n  by default.\n- **`--runner` chooses where load originates.** `local` runs from the\n  current machine/CI runner — bounded by its own resources, fine for\n  internal or low-scale targets. `postman-cloud` runs from Postman's\n  infrastructure — needed for realistic external-scale load, or once local\n  resources would cap the achievable VU count. `postman-cloud-static-ip`\n  is the same, from a static-IP range — needed when the target allowlists\n  by IP.\n- **`--pass-if \"less_than(p95, 500)\"` turns a load test into a gate.**\n  Metrics: `avg`, `p90`, `p95`, `p99`, `error_rate`, `rps`. Checked after the\n  run completes, not enforced live — a bad configuration still generates its\n  full load before the gate fails.\n- **`--use-mock` points the test at a mock instead of a real backend** — for\n  load-testing collection/script logic itself, or to baseline mock-only\n  latency and isolate app/network slowness from what the mock adds.\n- **`--setup-collection`/`--teardown-collection`** (cloud runner only) run\n  once before/after the whole test — for provisioning or cleanup, not\n  per-iteration setup.\n- **`--dataset-id`/`--dataset-view-id`** drive iteration data from a Postman\n  Dataset instead of a flat `--data-file`; `--dataset-distribution` controls\n  whether rows are spread round-robin, fixed, or randomly across VUs.\n\n## Critical Rules\n\n1. **Running this against a real, non-mock backend generates real load with\n   real consequences — confirm the target, VU count, and duration with the\n   user before running,** the same way any action with effects outside this\n   session gets confirmed. Default to a low `--vu-count` and short\n   `--duration` for a first run against anything live, or point it at a mock\n   (`--use-mock`) when the goal is testing the collection, not the backend.\n2. **A `--pass-if` gate doesn't stop the load early.** The full VU count and\n   duration run regardless of whether the threshold will ultimately pass —\n   plan for that cost, don't assume a failing gate means less traffic was\n   sent.\n3. **Cloud runners come from Postman's IP ranges.** Before assuming a\n   `postman-cloud` run will reach a target, check whether it's IP-allowlisted\n   — use `postman-cloud-static-ip` if so, rather than discovering the\n   mismatch as a wall of connection failures.\n\n## Verification\n\nState the actual metrics the run produced (p95, error rate, rps — whatever\nthe `--pass-if` checked, plus the ones it didn't) and whether the gate\npassed, not just that the run completed. State which runner actually\nexecuted it (`local`/`postman-cloud`/`postman-cloud-static-ip`) — that\ndetermines whether the numbers reflect the target's real-world reachability\nor only local-network conditions.\n"
}