Agent skill · Testing & QA

load-testing-plan

Write a load and performance testing plan for a service. Use when asked to create a performance test plan, write load testing documentation, define stress or soak test scenarios, or set performance regression gates for CI. Produces a complete test plan document with scenario definitions, k6/Locust script skeleton, threshold table, result interpretation guide, and CI integration steps.

mohitagw15856github.com/mohitagw15856GitHub ↗
claude-codecursorMIT
Install
npx skills add mohitagw15856/pm-claude-skills --skill load-testing-plan --agent claude-code

Same command for any agent — swap --agent for codex, cursor, copilot.

Facts
Files in the skill folder: 1
SKILL.md size: 16 KB
Bundled scripts: none
Path: skills/load-testing-plan/SKILL.md
Open the folder on GitHub →
Where it comes from
Stars: 1,255
Language: HTML

Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.

From the SKILL.md

# Load Testing Plan Skill Produce a complete load and performance testing plan for a service — covering test objectives, scenario definitions, tooling configuration, success thresholds, and CI integration. A good load testing plan eliminates ambiguity about what "performance is acceptable" means, so engineers can run tests and get a pass/fail answer without having to interpret raw numbers themselves. ## Required Inputs Ask for these if not already provided: - **Service name and key endpoints** — which endpoints are under test (path, method, typical request/response shape) - **Current traffic baseline** — current requests/sec, p50/p99 latency, error rate under normal load - **Peak traffic expectations** — expected peak RPS (e.g. 10× baseline for flash sales, or seasonality peak) - **SLO targets** — latency SLOs (p99 < X ms), error rate SLO (< Y%), availability target - **Preferred testing tool** — k6, Locust, JMeter, Gatling, or no preference - **Test environment availability** — dedicated load test environment, staging, or production (with traffic shaping) ## Output Format --- # Load Testing Plan: [Service Name] **Author:** [Name] | **Team:** [Team name] **Date:** [Date] | **Review

What's inside
Steps it walks through
  1. Required Inputs
  2. Output Format
  3. 1. Objectives and Scope
  4. 2. Performance Targets (Success Criteria)
  5. 3. Traffic Model
  6. 4. Test Scenarios
  7. Scenario 1: Baseline (Steady-State)
  8. Scenario 2: Stress Test
  9. Scenario 3: Spike Test
  10. Scenario 4: Soak / Endurance Test
  11. 5. Test Environment Requirements
  12. Infrastructure
  13. Data Seeding
  14. 6. Tooling Setup
Commands it runs
Seed test users (needed for authenticated endpoint tests)
Seed test data for read endpoints
Verify seed completed
k6 — run baseline scenario
k6 run --env BASE_URL=https://[test-env-url] scripts/load_test.js
k6 — run stress scenario with output to InfluxDB
k6 run --out influxdb=http://[influxdb-host]:8086/k6 \
scripts/load_test.js
Locust — headless run
locust -f locustfile.py \
More from pm-claude-skills
All skills →
About this skill
What does the load-testing-plan skill do?

Write a load and performance testing plan for a service. Use when asked to create a performance test plan, write load testing documentation, define stress or soak test scenarios, or set performance regression gates for CI. Produces a complete test plan document with scenario definitions, k6/Locust script skeleton, threshold table, result interpretation guide, and CI integration steps.

How do I install it?

Run `npx skills add mohitagw15856/pm-claude-skills --skill load-testing-plan --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.

Where does this skill come from?

From mohitagw15856/pm-claude-skills, a repository with 1,255 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.

Is a popular skill a good skill?

Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.

Keep going