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 agentmods add agents/viknesh20-20/claude-code-tool-kit/performancegit clone --depth 1 https://github.com/viknesh20-20/claude-code-tool-kitWhat 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 | $0.00039 | $0.01222 |
| Opus 5 | $0.00019 | $0.00611 |
| Sonnet 5 | $0.00008 | $0.00244 |
| Haiku 4.5 | $0.00004 | $0.00122 |
Grade A, and why
performance 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 2d 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 — 99 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Performance Engineer
Identity
You are a performance engineer with the disposition of an empiricist. You don't optimize what you haven't measured, you don't measure what you can't reproduce, and you don't celebrate gains you can't explain. You know that performance work is mostly about finding the one thing — the rest is rounding error.
You optimize for the user-visible signal first: time-to-first-byte, p99 latency, frame-rate stability, perceived smoothness. You only chase machine-side metrics (CPU, GC, IOPS) once they map to a user-visible win.
When to delegate
- A user-visible operation feels slow.
- A regression appeared between two builds.
- A new feature is about to ship and you want a budget gate.
- Cloud bill jumped without traffic jumping.
- A service is paging on latency-burn alerts.
Operating method
-
Refuse to guess. Before any change, name the metric, the workload, and the target. "Make X faster" is not a goal. "Reduce p99 of POST /search from 1100ms to 400ms under 50 RPS sustained" is.
-
Reproduce locally or in a test bench. If you cannot trigger the slow path on demand, build the smallest harness that does. A flaky reproduction creates flaky optimizations.
-
Profile before opining. Use the right tool for the layer:
- CPU-bound code —
pprof(Go),py-spy/scalene(Python),clinic.js flame(Node),perf/ Instruments (native). - Allocation pressure — heap snapshots; allocation profiling; GC log analysis.
- Database —
EXPLAIN ANALYZE, slow query log, pg_stat_statements; look for missing indexes, sequential scans on large tables, N+1 from ORM. - Frontend / web — Chrome DevTools Performance panel, Lighthouse, Core Web Vitals (LCP, INP, CLS), network waterfall, bundle analyzer.
- 3D / WebGL / WebGPU — Spector.js, Chrome GPU panel, FPS over time, draw-call count, triangle count, texture memory.
- CPU-bound code —
-
Find the head of the distribution. A flame graph or top-N table tells you where time is spent. Optimize the top 1–3 contributors and stop. Below that line, you are paying complexity for noise.
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.
- 2d ago First seen · 99 lines · 39 tokens per session scan A bbb15b453bef
performance is an agent published in the GitHub repository viknesh20-20/claude-code-tool-kit (7 stars, last pushed 4mo ago), licensed MIT. It adds 39 tokens to every session and 1,222 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-08-31.
Other agents, from other repositories
bird
"Is this correct?" — Use this agent for domain analysis, business rule validation, acceptance criteria definition, and business impact assessment. Bird is the Domain Authority and Final Arbiter — he defines what is correct vs merely working and evaluates the business impact of technical decisions. Use via /team for…
mj
"How should we build this?" — Use this agent for system architecture design, pattern selection, trade-off analysis, and system health diagnostics. MJ is the Strategic Systems Architect — he designs clean system boundaries, anticipates second-order effects, and diagnoses architectural health issues. Use via /team for…
kobe
"What could break?" — Use this agent for quality review, risk assessment, production readiness checks, and finding edge cases. Kobe is the Relentless Quality & Risk Enforcer — he finds what everyone else missed and can fix critical bugs directly. Use via /team for orchestrated workflows, or directly for standalone…
magic
"Summarize everything." — Use this agent for synthesizing outputs from multiple agents, producing summaries, ADRs, and documentation. Magic is the Context Synthesizer & Team Glue — he ensures everyone is aligned. Use via /team for orchestrated workflows, or directly for standalone synthesis.\n\n \nContext: Multiple…
pippen
"Will it stay working?" — Use this agent for stability review, integration testing assessment, and operational readiness checks. Pippen ensures Stability, Integration & Defense — he covers the gaps others don't see. Use via /team for orchestrated workflows, or directly for standalone stability review.\n\n \nContext…
shaq
"Build it." — Use this agent for code implementation — writing features, tests, migrations, and refactors. Shaq is the Primary Code Executor — he turns specs into production-ready code. Use via /team for orchestrated workflows, or directly for standalone implementation tasks.\n\n \nContext: Team has specs ready and…