All tools
HarnessCurated · reviewed

Load-Test Harness

Updated Jul 7, 2026

A Claude Code project config and guide for authoring load and stress tests: scenario definitions, virtual-user ramp profiles, SLO thresholds for latency and error rate, and a structured pass/fail report. The harness keeps Claude focused on test design and analysis rather than ad-hoc scripting.

What it does

  • /loadtest

    Run a named load scenario and stream live metrics to completion.

  • /define-slo

    Interactively define SLO thresholds and write them to slo.json.

  • /slo-report

    Evaluate the latest test run against slo.json and return a PASS/FAIL report.

Files (2)

README.mdprimary · markdown · 3.7 KB
# Load-Test Harness

A Claude Code project configuration for designing, running, and evaluating load and stress tests.

## What it does

When this harness is active, Claude Code acts as a performance-testing engineer. It helps
you define realistic load scenarios, shape ramp profiles, set SLO thresholds, execute a
run, and produce a pass/fail report against those thresholds.

- **Scenario definitions:** Claude prompts you for endpoints, payloads, and concurrency
  targets before generating any script, so the test reflects real traffic patterns.
- **Ramp profiles:** Supports constant load, step ramps, and spike/soak variants. Claude
  explains the trade-off of each before you choose.
- **SLO gates:** You specify p95/p99 latency budgets and max error-rate; the report marks
  each SLO as PASS or FAIL against the measured values.
- **Tool focus:** The `settings.json` restricts bash to load-test runners and read-only
  commands, so Claude stays in test-analysis mode.

## Files in this harness

| File | Purpose |
|------|---------|
| `README.md` | This guide — Claude reads it as its working instructions |
| `settings.json` | Claude Code project settings — copy to `.claude/settings.json` |

## Setup

1. Copy `settings.json` to `.claude/settings.json` in your project root.
2. Open your project in Claude Code.
3. Tell Claude which load-testing tool you use and where the target service runs, e.g.:
   "We use k6 against a staging server at https://api-staging.example.com."

Claude will scaffold a scenario script, a `slo.json` thresholds file, and a run command.

## Workflow reference

### Defining a scenario
Tell Claude: "Define a load scenario for the `POST /orders` endpoint."

Claude will ask:
- What does a realistic request payload look like?
- What virtual-user count represents typical peak traffic?
- Are there authentication headers or session state to simulate?

Then it generates a k6/Locust/Artillery script and a companion `slo.json`.

### Running a test
Tell Claude: "Run the orders scenario at 50 VUs for 5 minutes."

Claude will execute the script, stream live metrics, and produce a structured summary
when the run completes.

### Evaluating results
Tell Claude: "Evaluate the last run against our SLOs."

Claude reads the test output, compares each metric against `slo.json`, and returns
a report with a PASS or FAIL verdict for each threshold and an overall go/no-go.

## Example output

```
SLO Report — POST /orders — 2026-07-07
──────────────────────────────────────
p95 latency   target: ≤ 300 ms   measured: 218 ms   ✓ PASS
p99 latency   target: ≤ 800 ms   measured: 540 ms   ✓ PASS
error rate    target: ≤ 0.1 %    measured: 0.03 %   ✓ PASS
throughput    target: ≥ 200 rps  measured: 312 rps  ✓ PASS

Overall verdict: PASS
```

## Commands

- `/loadtest <scenario>` — Run a named scenario and stream live metrics until completion.
- `/define-slo` — Interactively define SLO thresholds (latency, error rate, throughput)
  and write them to `slo.json`.
- `/slo-report` — Evaluate the most recent test run against `slo.json` and return a
  structured PASS/FAIL report.

## Allowed bash commands

The harness permits load-test runners and read-only inspection:

- `Bash(npx k6*)`, `Bash(k6*)` — k6 load tests
- `Bash(locust*)` — Locust load tests
- `Bash(npx artillery*)` — Artillery load tests
- `Bash(curl*)` — health-check the target before a run
- `Bash(git diff*)`, `Bash(git status*)`, `Bash(cat*)` — inspect scripts and results

Destructive commands and pushes are blocked.

## Known limitations

- The harness does not provision infrastructure; the target service must already be running.
- Distributed load (multiple load-generators) requires manual setup outside the harness.
settings.jsonJSON · 495 B
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(**)",
      "Edit(**)",
      "Bash(npx k6*)",
      "Bash(k6*)",
      "Bash(locust*)",
      "Bash(npx artillery*)",
      "Bash(artillery*)",
      "Bash(curl*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git log*)",
      "Bash(cat*)"
    ],
    "deny": [
      "Bash(git push*)",
      "Bash(git reset --hard*)",
      "Bash(git restore*)",
      "Bash(git clean*)",
      "Bash(rm -rf*)"
    ]
  }
}