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 skills/khaledsaeed18/dotclaude/performance-optimizationnpx skills add KhaledSaeed18/dotclaude --skill performance-optimizationgit clone --depth 1 https://github.com/KhaledSaeed18/dotclaudeWhat 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.00088 | $0.01161 |
| Opus 5 | $0.00044 | $0.00580 |
| Sonnet 5 | $0.00018 | $0.00232 |
| Haiku 4.5 | $0.00009 | $0.00116 |
Grade A, and why
performance-optimization 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 — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Profile first. Every performance intuition is wrong until the profiler confirms it. The code that looks slow is rarely the bottleneck; the bottleneck is almost always somewhere the code looks unremarkable. An optimization without a measurement is a guess. A guess that happens to speed things up does not mean you found the right thing.
The one rule
No change before you have a baseline measurement and a profiled bottleneck. If you cannot name the specific file, function, and line where the most time or memory is spent - with numbers - you are still in the investigation phase.
Step 1: Establish the baseline
Define what "slow" means in terms the problem must satisfy:
- What is the current measured value? (response time, frame rate, memory usage, query duration, build time)
- What is the target? (a budget from a spec, a regression from a previous version, a user-reported threshold)
- Can the scenario be reproduced reliably? If not, instrument first and gather data before optimizing.
Run the scenario and record the baseline:
# For Node.js / server-side
node --prof app.js # then: node --prof-process isolate-*.log
# or: clinic flame -- node app.js
# For queries
EXPLAIN ANALYZE SELECT ... # PostgreSQL
# or the equivalent for your database
# For browser / frontend
# Use the browser devtools Performance panel; record the scenario end-to-end
# Look at the flame chart, not just the summary
Save the baseline number. The optimization is only valid if the after-measurement is better than this.
Step 2: Find the bottleneck
Read the profiler output - do not guess from the source. Identify:
- The hot function: the one frame where the most CPU time is spent (not called the most - spent the most)
- The call chain: how does execution reach the hot function? What is the logical operation that triggers it?
- The bottleneck class: is this CPU-bound (computation), memory-bound (allocation/GC pressure), I/O-bound (disk or network latency), lock-bound (contention), or rendering-bound (layout/paint)?
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 · 97 lines · 88 tokens per session scan A 9cf985851778
performance-optimization is a skill published in the GitHub repository KhaledSaeed18/dotclaude (4 stars, last pushed 7d ago), licensed MIT. It adds 88 tokens to every session and 1,161 once invoked, about $0.0004 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 skills, from other repositories
release
Cut a new playback-mcp release — version bump, changelog, dev-to-main PR, tag, and npm publish via CI. Use when asked to plan or ship a new release/version.
pr
Open a pull request from dev into main for this repo, following the repo's checklist and template. Use when asked to open/create a PR, or as part of the release flow.
pyenv-native
Manages Python runtimes and project venvs via pyenv-native and pyenv-mcp. Use when installing Python, fixing which-python/venv issues, setting .python-version, pip env problems on Windows/Linux/macOS, or when MCP pyenv-native tools are available.
rpg
Build and query semantic code graphs using RPG-Encoder. Use BEFORE grep/cat/find for any question about code structure, behavior, relationships, impact, dependencies, or cross-file patterns.
src
use when generating a doc the user will read and share — specs, roadmaps, pr explainers, research reports, plans, strategy docs. trigger words: "glyph," "spec," "roadmap," "explainer," "report," "plan," "save as a doc.".
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.