/test-load

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select test-load from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv test-load, /just-vibe test-load and /jv:test-load in Claude. See shortcut setup and context examples.

What the agent does

1. Define the exact target, traffic shape, concurrency/rate/duration and stop thresholds, and validate isolation and side effects.
2. Establish a baseline and ramp within limits in a controlled environment with telemetry, observing latency, errors and resources.
3. Stop on thresholds and correlate saturation.

Inputs

• exact authorized endpoint/environment, workload, concurrency/rate/duration caps, and stop thresholds.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Controlled load/capacity experiment; execution needs explicit target and resource authorization.

Writes

Inspect/plan: inspect or propose; save requested artifacts only. Apply: make the requested changes or execute the requested operation within its resolved target and limits. Local preparation does not authorize live, remote, destructive or paid actions; existing explicit session authorization still applies.

Mode

Plan by default; apply to write the load script and run a bounded workload against the exact authorized target within the stated caps and stop thresholds. Requires exact authorized endpoint/environment, workload, concurrency/rate/duration caps, and stop thresholds.

Prerequisites

Defined behavior, existing test conventions/runners, isolated fixtures, and relevant dependencies. Requested bounded verification may use owned isolated fixtures without authorizing product edits or live-system tests. Never test destructive behavior against production by default; distinguish mocked behavior from real integration evidence.

Expected output

• Load script/protocol or run report with workload caps, time series, stop event, measured saturation boundary, bottlenecks and cleanup.

How the work is checked

• The configured request cap is enforced; rising errors or resource pressure triggers a bounded stop.

When to stop or clarify

• No third-party or production stress by assumption. Do not extrapolate measured capacity beyond the tested workload without qualifications.

Handling missing context

Infer

Read behavior contracts, existing runners and test conventions; distinguish fixture setup failure from a behavioral failure.

Assume

Use the smallest existing local runner and isolated synthetic fixtures that distinguish the requested behavior. When the method needs a library, runner, container runtime or load tool the project lacks, name the exact package or tool, the files it changes and any download, and add it only when the request authorizes new dev dependencies or tools; label a hand-written generator without shrinking, or a fake in place of a real dependency, as such.

Ask

Ask about an unresolved contract that changes the expected result, or the target/load limits before external testing; do not ask the user to choose a runner already configured.

Technical guidance

Evidence

Resolve exact authorized target, realistic workload, rate/concurrency/duration caps and resource stop thresholds.

Method

Model arrivals and user journeys explicitly; monitor server and client bottlenecks and isolate real payments/messages.

Pitfall

Closed-loop clients can hide overload by slowing request generation; averages conceal long tails and errors.

Check

Confirm healthy control load, bounded ramp and recovery, preserving actual achieved rates, tail latency and stop reason.

Situational decisions

When error rate or resource pressure crosses the declared cap: Stop traffic, preserve measurements and report the last stable level without extrapolating beyond it.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring