Workflows for performance testing

In brief: Dedicated TestChimp workflows scaffold k6, author scenario-linked journeys after a PR or release gap, run related performance tests, and upkeep composites—without folding k6 into /testchimp test.

Functional QA uses /testchimp test. Performance testing has its own catalog workflows. When to use which, typical sequences, and playbook pages: Performance testing workflows.

Agents follow Analyze → Plan → approval → Execute → Report, persist a plan under plans/knowledge/workflow_plans/<workflow-id>/, and close with report-agent-action. Absolute VUs/RPS/duration always come from you or run-perf-tests.policy.md—never from TrueCoverage sample rates.

All of these soft-gate org capability PERFORMANCE_TESTING. If it is absent and no trial is active, the workflow is N/A.

Which workflow to use

Goal	Command
First-time k6 scaffold + policies	/testchimp init-perf
Bring existing Locust / k6 / JMeter / Gatling / Artillery into k6/	/testchimp import-perf-tests
Author journeys for scenarios (PR, last-run, or nested under a release run)	/testchimp create-perf-tests
Execute related k6 after a PR, or for a release git range	/testchimp run-perf-tests
Maintain scenario links, composites, datasets, thresholds	/testchimp upkeep-perf

Cloud automations can invoke the same ids (create-perf-tests, run-perf-tests, upkeep-perf) on SDLC events. A common pattern: run related performance tests when a release is cut. See typical automation setups.

Scaffold: /testchimp init-perf

Run once per repo (or nested under create/import when k6/ is missing).

What it does:

• Copies portable k6 assets into <tests root>/k6/ (journeys/, composites/, profiles/, datasets/, lib/, scripts/)
• Patches Playwright testIgnore so **/k6/** is never treated as SmartTests
• Downloads @testchimp/k6 via prepare.sh (not vendored into git)
• Seeds run-perf-tests.policy.md, create-perf-tests.policy.md, and upkeep-perf.policy.md when missing
• Records a Performance testing note in plans/knowledge/ai-test-instructions.md (permitted env, seed/teardown, profile ownership, external mock inventory, and that perf is not inside Run QA)
• Offers nested import-perf-tests if an existing suite lives outside k6/

Do not run load/volume until absolute settings are approved. Smoke inspect is enough to prove the harness.

Full playbook: Init performance testing.

Author journeys: /testchimp create-perf-tests

Use this when you want new or updated k6 journeys linked to real #TS-… scenarios.

Typical scopes:

• After a PR / on a feature branch — scenarios and operations implicated by the diff
• Last-run delta on the default branch
• Nested under run-perf-tests for a release — same prior SHA → cut SHA range when existing journeys do not cover the cut (one extra approval, same plan file)

What the agent does (after you approve the plan):

1. Ranks candidates with scenario priority, semantic coverage, and get-requirement-coverage --include-perf. TrueCoverage demand is a relative ranking signal only (unavailable / sparse / mature).

2. Pulls redacted REAL E2E interaction shapes (list-api-operation-interactions) when API contract coverage is available—method, path template, schema shape, status class, timing distribution. Never credentials, cookies, or raw bodies.

3. Classifies each candidate as load, volume, or both; plans seed/teardown; inventories outbound deps with realistic mock latency.

4. Asks, for every composite change:

   Add <journey-id> to composite <composite-id> with relative weight <weight>? This changes only the mix; confirm the composite profile's absolute VUs/RPS/duration separately.

   Never silent membership.

5. Authors journey files with export const testchimp metadata (including volumeKind on volume journeys), uses smoke until load/volume is approved, writes plans/smart-smoke/<branch>/related-perf-tests.json with select-related.sh. /testchimp run QA also writes that file when journeys already exist.

Standalone prompt examples:

/testchimp create-perf-tests
/testchimp create-perf-tests for checkout
/testchimp create performance tests

Full playbook: Create performance tests.

Run related tests: /testchimp run-perf-tests

Script-first. CI and local wrappers work without an agent. The agent’s job is pick files, env, and (when asked) nested authoring.

After a PR (default)

On a feature branch, related journeys come from the change set (select-related.sh + list-related-perf-tests: scenarios, operations, paths, parent composites). On the default branch, the delta is since the last run-perf-tests run unless you name files.

/testchimp run-perf-tests
/testchimp run perf
/testchimp run performance tests

Export TESTCHIMP_API_KEY (and backend/ingress URLs when configured) into the k6 process. Resolve the target via connect-to-test-env. Reject production unless policy and user explicitly allow it.

Release-scoped

The release detail page copies a prompt like:

/testchimp run performance tests for release 1.2.0

Then the agent:

1. Fetches the release catalog (get-release) — cut SHA, prior release SHA.
2. Uses prior SHA → cut SHA as the git range (not the working-tree branch tip).
3. Builds related selection from that diff; stamps every wrapper run with TESTCHIMP_RELEASE and the cut SHA.
4. Sufficiency gate: if existing journeys do not cover the range (empty related set, changed operations with no tags, high-priority scenarios without PERF_TEST coverage), it asks whether to author.
   • Yes — nested create-perf-tests on the same git range, then run the new plus already-related tests.
   • No — run only related existing tests (or stop if none) and record the gap.
5. Points you at the release Performance Tests panel and Executions for ingest.

After ingest

Before a non-smoke run, agents query list-perf-baselines / list-perf-runs. After ingest, compare-perf-to-baseline runs only when environment, profile, dataset, LLM mode, and mock/latency profiles match. CLI exits nonzero when comparison.regressed is true. Agents do not weaken thresholds or “fix” a regression by changing the stub to 0 ms.

Full playbook: Run performance tests.

Maintain the suite: /testchimp upkeep-perf

Periodic hygiene for k6—parallel to /testchimp upkeep for SmartTests.

• Preserve stable testchimp.id values across moves/renames (branch copies are not distinct tests).
• Refresh redacted API shapes and seed contracts.
• Re-audit outbound deps on touched journeys.
• Change composite membership and weaken thresholds only when the approved plan says so.
• Compare new runs to baselines on matching dimensions; label everything else directional.

/testchimp upkeep-perf
/testchimp maintain performance tests

Full playbook: Upkeep performance tests.

Import an existing suite

If you already have Locust, k6, JMeter, Gatling, or Artillery outside k6/:

/testchimp import-perf-tests locust
/testchimp import perf tests perf/

Existing k6 request logic stays as-is. Other frameworks get a best-effort translate. Source VU counts are not copied into load profiles. Nested under init-perf it shares one approval.

Details: Import performance tests.

Policies

File	Role
run-perf-tests.policy.md	Permitted environments, capacity model (prod target vs local downsample), dependency mock/latency inventory, LLM mode
create-perf-tests.policy.md	Authoring conventions, scenario priority / semantic coverage flags, composite rules
upkeep-perf.policy.md	What may change without extra approval; threshold weakening always explicit

Init-perf seeds skeletons. Replace placeholders before non-smoke execution. See Policies.

Next

• k6 layout and captured metrics
• Viewing results and comparing runs
• Performance testing intro
• Concept: k6 vs JMeter vs Locust (import) · regression across releases · load testing patterns