Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add nimadorostkar/Claude-Skills-collection --skill performance-testinggit clone --depth 1 https://github.com/nimadorostkar/Claude-Skills-collectionWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/performance-testing)<a href="https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/performance-testing"><img src="https://agentmods.dev/badge/skills/nimadorostkar/claude-skills-collection/performance-testing/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/nimadorostkar/claude-skills-collection/performance-testing"><img src="https://agentmods.dev/badge/skills/nimadorostkar/claude-skills-collection/performance-testing.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00038 | $0.01539 |
| Opus 5 | $0.00019 | $0.00770 |
| Sonnet 5 | $0.00008 | $0.00308 |
| Haiku 4.5 | $0.00004 | $0.00154 |
Grade A, and why
performance-testing scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 131 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Performance Testing
Purpose
Find out where a system breaks, and why, before production finds out for you. A load test that reports "we handled 1,000 requests per second" without stating the latency, the error rate, and where the bottleneck was tells you nothing useful.
When to Use
- Before a known traffic event: a launch, a campaign, a migration.
- Establishing a capacity baseline.
- Verifying that a performance fix worked.
- Finding the breaking point of a new service.
Capabilities
- Workload modeling from real traffic patterns.
- Load profiles: smoke, load, stress, spike, soak.
- Measuring the right things: latency percentiles, error rate, saturation.
- Bottleneck identification across the stack.
- Result interpretation and capacity projection.
Inputs
- Real traffic patterns: the mix of endpoints, the shape of the day, the payload sizes.
- The target: expected load, and the load you must survive.
- A production-like environment. A test against a laptop measures the laptop.
Outputs
- The breaking point, and the component that broke.
- Latency percentiles at each load level, not an average.
- A capacity conclusion: what this system can serve, and where it needs work.
Workflow
- Model the workload from reality — Take the endpoint mix from production access logs. A test that hammers one endpoint measures that endpoint, not your system.
- Ramp, do not slam — Start below expected load and increase gradually. The point at which latency starts climbing is more informative than the point at which it falls over.
- Measure percentiles, never averages — An average latency of 200ms is consistent with half the users waiting 400ms. Report p50, p95, p99, and the maximum.
- Watch the system, not just the client — CPU, memory, connection pools, database locks, queue depth. The load generator tells you what happened; the system tells you why.
- Find the first bottleneck, fix it, repeat — There is always another one behind it. Performance testing is iterative.
- Soak test separately — Run at moderate load for hours. Memory leaks, connection leaks, and disk-filling logs only appear over time.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 131 lines · 38 tokens per session scan A d09606364f7d
performance-testing is a skill published in the GitHub repository nimadorostkar/Claude-Skills-collection (26 stars, last pushed 25d ago), licensed MIT. It adds 38 tokens to every session and 1,539 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
offensive-fuzzing
Practical offensive fuzzing methodology covering target identification, fuzzer selection (AFL++, libFuzzer, Honggfuzz, Boofuzz, syzkaller), harness writing, corpus curation, mutation strategies, coverage measurement, and crash triage. Use when setting up or running fuzz campaigns against any target: file parsers…
offensive-business-logic
Business logic vulnerability testing for web/mobile/API engagements. Covers workflow bypass, state machine violations, multi-step process abuse, price/quantity/discount manipulation, currency confusion, coupon stacking, refund/chargeback abuse, race conditions on logic boundaries, parameter tampering for hidden flows…
offensive-race-condition
Race condition (TOCTOU) testing checklist: identifying timing windows, Burp Suite Turbo Intruder, Last-Byte sync technique, rate limit bypass, double-spend attacks, and concurrent request exploitation. Use for web app race condition testing or bug bounty time-of-check-to-time-of-use bugs.
smoke-test
Launch the app and hands-on verify that it works by interacting with it. Falls back to an existing integration test suite when there is no interactive surface in scope. Use when the user asks to "smoke test", "test it manually", "verify it works", "try it out", "run a smoke test", "check it in the browser", or "does…
exploratory-test
Execute multi-level exploratory testing of the app covering basic functionality, complex operations, adversarial testing, and cross-cutting scenarios, plus usability observations through a UX lens reported separately from defects. Deeper than /smoke-test. Use when the user asks to "exploratory test", "test…
create-test-plan
Analyze what changed and generate a structured test plan at .turbo/test-plans/ .md covering four escalating levels: basic functionality, complex operations, adversarial testing, and cross-cutting scenarios. Use when the user asks to "create a test plan", "plan tests", "what should I test", "generate test scenarios"…