What this prompt does
This prompt builds a load testing suite for a chosen [load_tool] and [app_type]. You define the [scenarios] to simulate, and the AI writes virtual-user scripts with realistic think times and parameterised data, a ramp-up plan (start at [start_vus] users, climb to [peak_vus] over [ramp_duration], hold for [hold_duration]), performance thresholds (p95 under [p95_target]ms, errors under [error_target]%), dynamic value correlation, custom KPI metrics, HTML reporting, CI integration as a nightly job, and baseline comparison.
The structure works because it turns vague performance worries into measurable thresholds. By forcing explicit ramp-up, hold, and p95/error targets, the prompt produces tests that answer "is this fast enough" with numbers instead of feelings. Correlating dynamic values (tokens, IDs) keeps the simulated traffic realistic, and the [scenarios] plus [peak_vus] variables scale the test to the system's expected load.
When to use it
- You expect a traffic spike and want to know the system's real breaking point first.
- You need realistic virtual-user scripts with think times for
[scenarios]. - You want a defined ramp-up and hold profile rather than a flat blast.
- You need enforceable p95 and error-rate thresholds.
- You want load tests running nightly in CI with baseline comparison.
- You need dynamic tokens and IDs correlated so requests do not fail spuriously.
Example output
You get a [load_tool] project: scripted scenarios with think times and parameterised data, a staged executor ramping from [start_vus] to [peak_vus] over [ramp_duration] then holding [hold_duration], threshold definitions for [p95_target]ms p95 and [error_target]% errors, correlation logic for dynamic values, custom metrics, an HTML report, and a CI job for nightly runs.
Pro tips
- Set
[peak_vus]to a number grounded in real or projected traffic, not a round guess. - Describe
[scenarios]as full user journeys so think times and pacing are realistic. - Tune
[p95_target]and[error_target]to your SLOs; thresholds that are too loose hide problems, too tight cause noise. - Make sure dynamic correlation covers every token and ID your
[app_type]issues, or requests will fail under load for the wrong reason. - Run a short smoke profile before the full
[ramp_duration]to catch script errors cheaply. - Compare against a stored baseline each run so you spot regressions, not just absolute numbers.
