Api load tester

Skill bg-szy/TOP-SKILLS/skills/claude-skills/api-load-tester

全球最大的 Claude Code 技能聚合库 · 收录 3900+ 来自 12+ 来源的技能，提供在线搜索与趋势分析看板 / The world's largest Claude Code skill aggregation hub — 3900+ skills from 12+ sources with online search and trend dashboard

Install

npx -y skills add bg-szy/TOP-SKILLS --skill api-load-tester

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Load tests API endpoints with progressive concurrency. Measures response times, error rates, throughput, and identifies breaking points. Generates a detailed report with latency percentiles, throughput curves, bottleneck analysis, and optimization recommendations.

SKILL.md

3.7 KB, 731 tokens by cl100k_base, as published. Nobody here has run it

API Load Tester

Stress-test HTTP endpoints under increasing load, identify breaking points, and produce a report with actionable recommendations.

references/tool-commands.md -- tool invocations (hey/wrk/ab/curl), default concurrency stages, per-stage data to capture.
references/metrics-interpretation.md -- latency, throughput, error, breaking-point, and bottleneck classification.
references/output-template.md -- exact structure for api-load-report.md, including ASCII charts and scaling table.
references/rules-and-examples.md -- safety rules, error handling, and example invocations.

Inputs

Collect from the user. Ask before proceeding if a required input is missing.

Required: endpoint URL(s) (with method, headers, body as needed); expected latency thresholds. Default thresholds if unspecified: p50 < 100ms, p95 < 300ms, p99 < 1000ms.

Optional: concurrent users or range (default ramp 1 to 100); authentication; request payloads; custom headers; test duration (default 10s per stage); ramp pattern (default step ramp, doubling each stage); success criteria (default 2xx); known rate limits; environment label (prod/staging/dev).

Workflow

Follow these steps in order.

Select a tool. Check in priority order: which hey, which wrk, which ab, which curl. If none of hey/wrk/ab exist, install hey (brew install hey on macOS, go install github.com/rakyll/hey@latest on Linux with Go) or fall back to curl with bash background processes and wait. Verify with a single trivial request against a provided endpoint; diagnose connectivity or auth before continuing.
Validate endpoints. Send one request per endpoint with the specified method, headers, auth, and body. Confirm the status matches the success criteria and record baseline single-request latency. On failure, surface the error and ask whether to skip or fix.
Design the test plan. Build progressive concurrency stages (see references/tool-commands.md for the default progression), trimming or extending to the user's concurrency range. Define per-endpoint method, URL, headers, body, success codes, and timeout (default 30s). Print the plan for review before executing.
Execute stages. For each endpoint, run every concurrency stage sequentially with the selected tool, waiting 2 seconds between stages. Capture and store the per-stage metrics. See references/tool-commands.md for commands, request-count formula, and the metrics list.
Interpret metrics. Compute latency percentiles and profile, throughput curve and ceiling, error rates and onset, the breaking point, and the bottleneck classification. See references/metrics-interpretation.md.
Generate the report. Write api-load-report.md to the current working directory following references/output-template.md exactly, including ASCII throughput and latency charts.
Post-report actions. Print a 3-5 line summary to the console, state the report path, explicitly highlight any critical issues, and offer to re-run specific stages with different parameters.

Rules

Apply the safety rules, error handling, and example invocations in references/rules-and-examples.md. Key constraints: never load-test production without explicit confirmation, only test GET by default, mask auth tokens, respect 429 rate limits, count timeouts as failures, and never extrapolate beyond tested ranges.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most performance cost skills give in 731 tokens

Counted across 803 of the 1,058 authors here whose files we hold, read 2026-08-07

Keep skill files under 500 lines or tokensin 82 of 803, across 16 files
Use imperative form in instructionsin 80 of 803, across 9 files
Draft assertions while test runs are in progressin 75 of 803, across 9 files
Create two to three realistic test promptsin 74 of 803, across 9 files
Write skill descriptions to be pushyin 72 of 803, across 7 files
Save test cases to evals JSONin 72 of 803, across 6 files
Ask questions about edge cases and input formatsin 72 of 803, across 7 files
Save timing data immediately when runs completein 70 of 803, across 5 files
Include all trigger conditions in the skill descriptionin 69 of 803, across 3 files
Launch all test runs in a single turn or simultaneouslyin 69 of 803, across 3 files
Capture intent before writing a skillin 67 of 803, across 1 file
Import directly instead of barrel filesin 52 of 803, across 15 files

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.