qa-load-testing

Action-taking agent that reads a target project's stack + load-testing goal (RPS profile, soak duration, browser-side metrics, CI gating) and recommends ONE load testing tool - k6 (JS scripts), JMeter (GUI / XML scenarios), Gatling (Scala DSL), Locust (Python), or Lighthouse (browser-side perf budgets) - plus rationale and the preloaded SKILL.md to read next. Distinct from `qa-load-testing/perf-regression-bisector` (bisects regressions in EXISTING load-test data). Use when starting a new load testing effort and the team has not yet committed to a tool.

Action-taking on-call orchestrator that confirms a live performance incident, reproduces it under k6 load, flame-graphs the hot path, detects slow queries, localizes the dominant cause, and emits a triage report with a recommended fix. Distinct from `perf-regression-bisector` (which bisects commits to find the introducing change) - this agent acts on an active incident where the symptom is confirmed but the cause is unknown. Use when an alert, APM spike, or customer report signals a performance incident and the on-call engineer needs to localize the cause under time pressure.

Action-taking agent that bisects a performance regression across commits - drives `git bisect run` with a per-commit perf measurement script (typically a k6 / Lighthouse run with a single budget assertion), identifies the introducing commit, and hands off the in-commit hot path to flame-graph-analyzer or db-slow-query-detector for application-level diagnosis. Use when load testing or Lighthouse CI shows a perf regression but the introducing commit is unclear.

Reads `EXPLAIN` / `EXPLAIN ANALYZE` output from PostgreSQL, MySQL, or SQLite - identifies the dominant cost (sequential scan, nested loop, sort spill, missing index, type-cast preventing index use), proposes the specific index or query rewrite to fix it, and emits the candidate `CREATE INDEX` statement. Use when load testing or production telemetry shows the database as the bottleneck and the team needs targeted query-level remediation.

Reads CPU flame-graph output from py-spy (Python), async-profiler (JVM), Go pprof, or Node.js perf_hooks / clinic.js - identifies the hot path (top sample-time stack frames), classifies the bottleneck (CPU-bound vs lock contention vs allocator pressure), and proposes the next investigation step. Use when a perf regression has been bisected to a commit but the hot path inside that commit is unclear.

Authors Gatling simulations in Java / Kotlin / Scala (or JS / TS) using the Simulation class plus http() / scenario() / exec() DSL builders, ramps virtual users via injectOpen (arrival rate) or injectClosed (concurrent count), runs via Maven / Gradle / sbt with the Gatling plugin, and gates CI on assertions defined in setUp(). Use when the project is on the JVM and the team prefers code-first load tests over JMeter's XML or k6's JavaScript-only authoring.

Orients an engineer who is new to performance and load testing through the qa-load-testing plugin: explains the core metrics (throughput, latency percentiles, error rate), selects the right tool via the load-test-tool-selector agent, walks the first k6 script through to a passing threshold, adds a perf-budget-gate CI step, and routes failing results to latency-percentile-analyzer or perf-incident-responder. Use when an engineer new to performance or load testing does not know where to start in this plugin.

Authors Apache JMeter `.jmx` test plans (Thread Groups + HTTP samplers + assertions + listeners) in the JMeter GUI, runs them headlessly via `jmeter -n -t plan.jmx -l results.jtl`, generates an HTML dashboard with `-e -o`, and gates CI on JTL parsing. Use when the project has an existing JMeter investment, needs JVM-native load tooling, or works in domains with strong JMeter community support (banking, telecom, enterprise).