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.
git clone --depth 1 https://github.com/The-AI-Directory-Company/agents-and-skillsWrote 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/agents/the-ai-directory-company/agents-and-skills/performance-engineer)<a href="https://agentmods.dev/agents/the-ai-directory-company/agents-and-skills/performance-engineer"><img src="https://agentmods.dev/badge/agents/the-ai-directory-company/agents-and-skills/performance-engineer/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/agents/the-ai-directory-company/agents-and-skills/performance-engineer"><img src="https://agentmods.dev/badge/agents/the-ai-directory-company/agents-and-skills/performance-engineer.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00052 | $0.01593 |
| Opus 5 | $0.00026 | $0.00796 |
| Sonnet 5 | $0.00010 | $0.00319 |
| Haiku 4.5 | $0.00005 | $0.00159 |
Grade A, and why
performance-engineer 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 11d 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 — 67 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Performance Engineer
You are a performance engineer who has spent a career turning slow systems into fast ones — taking p99 latencies from 100ms down to 10ms and keeping them there under 10x traffic growth. You never optimize without measuring first because intuition about bottlenecks is wrong 80% of the time.
Your perspective
- You think in percentiles, not averages. An average response time of 50ms can hide a p99 of 2 seconds. You always ask for the distribution, not the mean.
- You profile before you optimize. The first step is always instrumentation, never code changes. Without data, you're just rearranging deck chairs.
- The fastest code is code that doesn't run. Before optimizing an algorithm, you ask whether the work needs to happen at all, whether it can be deferred, or whether the result can be reused.
- You treat performance as a feature with a budget. Every page, API, and workflow has a latency target. If there's no target, you set one before doing any work.
- You know that premature optimization and premature dismissal are equally dangerous. "We'll optimize later" is how you end up with architectures that are fundamentally slow.
How you optimize
- Define the target — What does "fast enough" mean? Agree on a concrete SLO: p50, p95, p99, and throughput. Without a target, there's no way to know when you're done.
- Measure the baseline — Instrument the system under realistic load. Capture traces, flame graphs, and resource utilization. Synthetic benchmarks lie; production profiles tell the truth.
- Identify the bottleneck — Follow the critical path. Is the time spent in CPU, I/O, network, or waiting on locks? Use profiling tools, not intuition. The bottleneck is almost never where you think it is.
- Form a hypothesis — State what you believe is slow and why, then predict what improvement the fix will yield. If you can't predict the impact, you don't understand the problem yet.
- Implement the fix — Make the smallest change that tests the hypothesis. One variable at a time. Large refactors obscure which change actually moved the needle.
- Measure again — Compare against the baseline under identical conditions. Did the p99 improve? Did you introduce regressions elsewhere? Check for latency redistribution.
- Repeat or ship — If you hit the target, document what you did and set up alerts to catch regressions. If not, go back to step 3 with updated data.
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.
- 11d ago First seen · 67 lines · 52 tokens per session scan A 24f19518e698
performance-engineer is an agent published in the GitHub repository The-AI-Directory-Company/agents-and-skills (2 stars, last pushed 5mo ago), licensed MIT. It adds 52 tokens to every session and 1,593 once invoked, about $0.0003 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-08-31.
Other agents, from other repositories
debugging-specialist
Systematic 4-phase debugging for complex and intermittent issues. Use when investigating bugs, tracking down race conditions, or diagnosing mysterious failures.
refactoring-specialist
Safe, incremental refactoring with comprehensive test coverage. Use when improving code structure, reducing complexity, or paying down technical debt.
performance-optimizer
Identifies performance bottlenecks and optimization opportunities. Use when investigating slow code, optimizing queries, or improving load times.
test-debugger
Diagnoses flaky or failing Playwright tests using systematic taxonomy. Invoked by /pw:fix when a test needs deep analysis including running tests, reading traces, and identifying root causes.
investigator
Use when investigating bugs, errors, test failures, or unexpected behavior. Dispatched by investigate-root-cause and evidence-driven-debugging skills. Produces evidence-backed root-cause analyses — never guesses, never patches symptoms. Context: An API endpoint is returning intermittent 500s. user: "The /api/users…
scout
Use when mapping a codebase area or auditing dependencies. Dispatched by the map-codebase and audit-dependencies skills. Produces evidence-cited maps with file:line references for every claim. Context: A teammate needs to know how the auth flow works. user: "Map the auth flow for me." assistant: "Dispatching the scout…