メニュー
Use when code is slow, resource-heavy, or needs optimization — before making any changes, after profiling reveals bottlenecks, or when designing performance-sensitive systems
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | performance-optimization |
| description | Use when code is slow, resource-heavy, or needs optimization — before making any changes, after profiling reveals bottlenecks, or when designing performance-sensitive systems |
Measure first, optimize second. Never optimize without data. The bottleneck is almost never where you think it is.
1. Measure baseline Before touching anything, establish a benchmark.
2. Profile to find the bottleneck Use profiling tools appropriate to your stack:
cProfile, py-spy, memory_profiler--prof, clinic.js, Chrome DevToolspprofThe bottleneck is the one place where optimization actually matters.
3. Form hypothesis State explicitly: "I believe X is slow because Y." Don't optimize something you can't explain.
4. Apply targeted fix Change ONE thing at a time. Common high-impact areas:
5. Measure again Compare to baseline. Did it improve? If not, revert and try something else.
6. Document the change Record what you changed, why, and the before/after numbers.
| Area | Look For |
|---|---|
| Database | N+1 queries, full table scans, missing indexes |
| Caching | Repeated expensive computations with same inputs |
| Network | Chatty APIs, large payloads, synchronous chains |
| Algorithms | Nested loops over large collections |
| Memory | Objects created in tight loops, large in-memory datasets |
| Thought | Reality |
|---|---|
| "This looks slow" | Measure it. Looks are deceiving. |
| "I'll optimize as I go" | Premature optimization obscures intent. Measure first. |
| "I fixed the bottleneck" | Did you measure? Fix without measurement isn't a fix. |
| "This is the obvious bottleneck" | Profile anyway. You're probably wrong. |
Use when adding new dependencies, deciding whether to update packages, running security audits on dependencies, evaluating library alternatives, or encountering outdated or vulnerable packages
Use when starting any conversation — establishes how to find and use skills, requiring skill check before ANY response including clarifying questions
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when you have a spec or requirements for a multi-step task, before touching code
Use when a task requires interacting with a web browser — testing UI flows, verifying web app behavior, clicking through screens, reading live web content, or automating browser workflows in Google Antigravity