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 KhaledSaeed18/dotclaude --skill performance-optimizationgit clone --depth 1 https://github.com/KhaledSaeed18/dotclaudeWrote 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/khaledsaeed18/dotclaude/performance-optimization)<a href="https://agentmods.dev/skills/khaledsaeed18/dotclaude/performance-optimization"><img src="https://agentmods.dev/badge/skills/khaledsaeed18/dotclaude/performance-optimization/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/khaledsaeed18/dotclaude/performance-optimization"><img src="https://agentmods.dev/badge/skills/khaledsaeed18/dotclaude/performance-optimization.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.00067 | $0.01140 |
| Opus 5.5 | $0.00027 | $0.00456 |
| Sonnet 5.5 | $0.00013 | $0.00228 |
| Haiku 4.5 | $0.00007 | $0.00114 |
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 28d 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.
- 28d ago Changed · -21 tokens per session b2677188c40a
- 1mo ago First seen · 97 lines · 88 tokens per session scan A 9cf985851778
performance-optimization is a skill published in the GitHub repository KhaledSaeed18/dotclaude (5 stars, last pushed 6d ago), licensed MIT. It adds 67 tokens to every session and 1,140 once invoked, about $0.0003 per session on Opus 5.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
ast-grep
Searches and rewrites code by AST shape across 25 languages. Use when the target is a syntax pattern (every call/class/import shaped like X, a codemod, a YAML rule) rather than literal text; for plain strings, comments, or filenames, use rg.
debugging
Runs a hypothesis-driven debugging loop across any language or binary, escalating to orthogonal oracle angles and locking the fix with a failing test. Use for crashes, silent failures, hangs, wrong responses, memory leaks, async misbehavior, or reverse engineering.
lcx-doctor
Diagnose LazyCodex and Codex CLI installation health against the latest sources. Use whenever the user asks for a doctor or health check, says LazyCodex, lazycodex-ai, omo-codex, or Codex behaves oddly after an install, update, or config change, suspects a stale, drifted, or broken setup, or wants the local install…
lcx-report-bug
Create a high-signal bug issue or PR in the repo that owns the defect. Use this whenever the user asks to report, file, open, or triage a LazyCodex, lazycodex-ai, omo-codex, Codex plugin, or upstream Codex CLI bug, especially when they need source-backed root cause, reproduction steps, fix guidance, and GitHub routing.
remove-deadcode
Remove unused code from this project with ultrawork mode, LSP-verified safety, atomic commits. Triggers: remove dead code, dead code, cleanup, remove unused.
code-review-web
Review web application code for bugs, security issues, performance problems, and stack-specific anti-patterns. Use this skill whenever the user wants to review code, debug a production issue, investigate a build failure, audit security, or check a PR before merging. Triggers on code review, review my code, debug…