Update to Postman

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,71 +1,55 @@
 ---
 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.
+description: Use when load-testing or benchmarking an API with concurrent virtual users and latency or error thresholds. Reuses a collection to probe a chosen failure mode and distinguishes target limits from load-generator limits. Use for requests such as "load test this API".
 ---
 
 # Performance Testing
 
-## Overview
-
-`performance run <collectionId>` is not `collection run` with more
-iterations — it's a dedicated load-test mode: many virtual users hitting the
-collection concurrently for a set duration, shaped by a load profile, scored
-against thresholds you define, on infrastructure you choose. The collection
-under test is authored the normal way — see the `collection-schema-v3` skill
-if it needs edits before the load test is meaningful (e.g. an assertion
-that would fail every VU's request identically).
-
-## Core knowledge
-
-- **Load profile is what you're actually testing.** `fixed` holds steady
-  concurrency (does this hold up at N users, sustained); `ramp-up` increases
-  gradually (where does it start to degrade); `spike` bursts suddenly (does
-  a sudden surge break it); `peak` sustains near-maximum load (does it
-  survive staying there). Pick based on the failure mode being probed, not
-  by default.
-- **`--runner` chooses where load originates.** `local` runs from the
-  current machine/CI runner — bounded by its own resources, fine for
-  internal or low-scale targets. `postman-cloud` runs from Postman's
-  infrastructure — needed for realistic external-scale load, or once local
-  resources would cap the achievable VU count. `postman-cloud-static-ip`
-  is the same, from a static-IP range — needed when the target allowlists
-  by IP.
-- **`--pass-if "less_than(p95, 500)"` turns a load test into a gate.**
-  Metrics: `avg`, `p90`, `p95`, `p99`, `error_rate`, `rps`. Checked after the
-  run completes, not enforced live — a bad configuration still generates its
-  full load before the gate fails.
-- **`--use-mock` points the test at a mock instead of a real backend** — for
-  load-testing collection/script logic itself, or to baseline mock-only
-  latency and isolate app/network slowness from what the mock adds.
-- **`--setup-collection`/`--teardown-collection`** (cloud runner only) run
-  once before/after the whole test — for provisioning or cleanup, not
-  per-iteration setup.
-- **`--dataset-id`/`--dataset-view-id`** drive iteration data from a Postman
-  Dataset instead of a flat `--data-file`; `--dataset-distribution` controls
-  whether rows are spread round-robin, fixed, or randomly across VUs.
-
-## Critical Rules
-
-1. **Running this against a real, non-mock backend generates real load with
-   real consequences — confirm the target, VU count, and duration with the
-   user before running,** the same way any action with effects outside this
-   session gets confirmed. Default to a low `--vu-count` and short
-   `--duration` for a first run against anything live, or point it at a mock
-   (`--use-mock`) when the goal is testing the collection, not the backend.
-2. **A `--pass-if` gate doesn't stop the load early.** The full VU count and
-   duration run regardless of whether the threshold will ultimately pass —
-   plan for that cost, don't assume a failing gate means less traffic was
-   sent.
-3. **Cloud runners come from Postman's IP ranges.** Before assuming a
-   `postman-cloud` run will reach a target, check whether it's IP-allowlisted
-   — use `postman-cloud-static-ip` if so, rather than discovering the
-   mismatch as a wall of connection failures.
+A collection supplies realistic request sequences; `postman performance run`
+adds concurrency and a load profile. This makes performance claims repeatable,
+but only for the workload, data, and network path actually exercised.
+Collections run directly: converting with `postman-to-k6` is not required.
+
+1. Choose the failure mode before the profile: `fixed` tests sustained
+   concurrency, `ramp-up` explores degradation as load grows, `spike` tests
+   sudden surges, and `peak` tests staying near maximum load. Reuse the
+   collection's auth and assertions, and check that its operations and data
+   represent the workload rather than repeating one unusually cheap request.
+2. Establish the target, VU count, duration, and effects of write requests
+   before sending load. Existing user authorization for that scope is enough;
+   resolve missing limits before stressing a shared or production service.
+   Thresholds are evaluated after the run, so a failing gate will not stop
+   traffic early. A small initial run can expose wiring failures before a
+   larger authorized test.
+3. Choose the runner by reachability and capacity. `local` uses this machine
+   or CI runner; its CPU or network can become the bottleneck. `postman-cloud`
+   moves generation to Postman's infrastructure, while
+   `postman-cloud-static-ip` supports targets with IP allowlists. Verify
+   reachability before interpreting connection failures as service capacity.
+4. Set thresholds that represent the user's objective, such as
+   `--pass-if "less_than(p95, 500)"`. Supported metrics include `avg`, `p90`,
+   `p95`, `p99`, `error_rate`, and `rps`; latency alone can look good when
+   requests fail quickly. Use `postman performance run -h` for current syntax,
+   units, and runner-specific options.
+5. Isolate test data where concurrent writes would collide. **datasets**
+   supports controlled row distribution across VUs; setup/teardown collections
+   on hosted runners execute once around the test, not once per iteration.
+   `--use-mock` can baseline collection/script overhead, but its numbers
+   cannot establish the real backend's capacity.
+
+## Importing from JMeter
+
+Have a JMeter `.jmx` instead of a collection? Don't rebuild it by hand — run the
+bundled importer (`references/jmeter-import/scripts/jmx_to_postman.py <plan>.jmx
+-o <out>`; see `references/jmeter-import/README.md`), then treat its output as the
+collection above. Read the generated report: it marks what mapped exactly, what
+was approximated, and which JMeter features have no equivalent here — think-time
+timers, concurrent thread groups, and non-HTTP (JDBC/FTP/LDAP/Java) samplers are
+reported, never faked.
 
 ## Verification
 
-State the actual metrics the run produced (p95, error rate, rps — whatever
-the `--pass-if` checked, plus the ones it didn't) and whether the gate
-passed, not just that the run completed. State which runner actually
-executed it (`local`/`postman-cloud`/`postman-cloud-static-ip`) — that
-determines whether the numbers reflect the target's real-world reachability
-or only local-network conditions.
+Report the workload, runner, achieved traffic, latency and error metrics,
+and threshold verdict. Identify generator limits or target errors that prevent
+attributing the result to API capacity. See **api-testing** for functional
+assertions and **ci-integration** when the measured threshold becomes a gate.