ワンクリックでManusで任意のスキルを実行

始める

performance-optimization

スター32

フォーク3

更新日2026年3月21日 13:14

Use when optimizing code performance, addressing slowness complaints, or measuring application speed improvements

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

JeremyDev87

JeremyDev87/codingbuddy

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Performance Optimization

Iron Law: NO OPTIMIZATION WITHOUT PROFILING FIRST

No exceptions - not for "obvious" bottlenecks, "quick wins", or "best practices".

Use for: Slow APIs, UI lag, high memory, slow builds, database queries, any "make it faster" request.

Five Phases

Phase	Activity	Output
1. Profile	Find hot paths with profiler	Bottlenecks with % of time
2. Benchmark	5 warm-up + 10 measured runs	Baseline with mean, std, p95
3. Prioritize	Apply Amdahl's Law	ROI-ranked list
4. Optimize	ONE change, verify	Measured improvement
5. Prevent	CI gates, monitoring	Regression detection

Phase 1: Profile

Clarify metrics ("It's slow" → p50? p95?)
Select profiler:
- CPU: perf, py-spy, node --prof, Chrome DevTools
- Memory: heaptrack, memray, Chrome Memory
- I/O: strace, iostat, slow query log
- Distributed: OpenTelemetry, Jaeger, Datadog
- Serverless: AWS X-Ray, CloudWatch
- Mobile: Android Profiler, Xcode Instruments
Profile cold AND warm cache
Flame graphs: Wider bars = more time
Time-box: Max 2 hours → Escalate if unclear

Phase 3: Prioritize (Amdahl's Law)

Formula: Speedup = 1 / ((1 - P) + P/S)

Bottleneck %	Max Speedup	Action
< 5%	< 1.05x	Skip
5-20%	1.05-1.25x	Low priority
20-50%	1.25-2x	Medium
> 50%	> 2x	High priority

Multiple similar %? Optimize easiest first. Re-profile after each.

Phase 4: Optimize

Write benchmark test first
ONE change at a time
Compare statistically
Rollback: Separate commit, feature flags

Phase 5: Prevent

Add CI gate: PERF_BUDGET_MS: 150 → fail build if exceeded

Red Flags - STOP

"I know where the bottleneck is" → Profile first
"Let's just add caching" → Measure first
"One run is enough" → High variance
"The fix is obvious" → Return to Phase 1

Rationalizations

Excuse	Reality
"I know the bottleneck"	Profiling surprises 90% of time
"Micro-optimizations add up"	Amdahl's Law: 5% code = 95% time

See documentation-template.md for before/after template.

このリポジトリの他の Skills

同じリポジトリ

taskmaestro

JeremyDev87/codingbuddy

Use when orchestrating parallel Claude Code instances across tmux panes with git worktree isolation — managing multiple concurrent development tasks visually

2026-04-0532

incident-response

JeremyDev87/codingbuddy

Use when production incident occurs, alerts fire, service degradation detected, or on-call escalation needed - guides systematic organizational response before technical fixes

2026-04-0532

pr-review

JeremyDev87/codingbuddy

Use when conducting manual PR reviews - provides structured checklist covering security, performance, maintainability, and code quality dimensions with anti-sycophancy principles

2026-04-0532

ship

JeremyDev87/codingbuddy

Run local CI checks and ship changes — create branch, commit, push, and PR. Optionally link to a GitHub issue. Use when changes are ready to ship.

2026-04-0332

systematic-debugging

JeremyDev87/codingbuddy

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

2026-04-0332

widget-slot-architecture

JeremyDev87/codingbuddy

Architecture guide using Next.js App Router's Parallel Routes for Widget-Slot pattern. Separates static layouts from dynamic widgets to achieve separation of concerns, fault isolation, and plug-and-play development.

2026-04-0232

name	performance-optimization
description	Use when optimizing code performance, addressing slowness complaints, or measuring application speed improvements
context	fork
agent	general-purpose
allowed-tools	Read, Grep, Glob, Bash

Performance Optimization

Iron Law: NO OPTIMIZATION WITHOUT PROFILING FIRST

No exceptions - not for "obvious" bottlenecks, "quick wins", or "best practices".

Use for: Slow APIs, UI lag, high memory, slow builds, database queries, any "make it faster" request.

Five Phases

Phase	Activity	Output
1. Profile	Find hot paths with profiler	Bottlenecks with % of time
2. Benchmark	5 warm-up + 10 measured runs	Baseline with mean, std, p95
3. Prioritize	Apply Amdahl's Law	ROI-ranked list
4. Optimize	ONE change, verify	Measured improvement
5. Prevent	CI gates, monitoring	Regression detection

Phase 1: Profile

Clarify metrics ("It's slow" → p50? p95?)
Select profiler:
- CPU: perf, py-spy, node --prof, Chrome DevTools
- Memory: heaptrack, memray, Chrome Memory
- I/O: strace, iostat, slow query log
- Distributed: OpenTelemetry, Jaeger, Datadog
- Serverless: AWS X-Ray, CloudWatch
- Mobile: Android Profiler, Xcode Instruments
Profile cold AND warm cache
Flame graphs: Wider bars = more time
Time-box: Max 2 hours → Escalate if unclear

Phase 3: Prioritize (Amdahl's Law)

Formula: Speedup = 1 / ((1 - P) + P/S)

Bottleneck %	Max Speedup	Action
< 5%	< 1.05x	Skip
5-20%	1.05-1.25x	Low priority
20-50%	1.25-2x	Medium
> 50%	> 2x	High priority

Multiple similar %? Optimize easiest first. Re-profile after each.

Phase 4: Optimize

Write benchmark test first
ONE change at a time
Compare statistically
Rollback: Separate commit, feature flags

Phase 5: Prevent

Add CI gate: PERF_BUDGET_MS: 150 → fail build if exceeded

Red Flags - STOP

"I know where the bottleneck is" → Profile first
"Let's just add caching" → Measure first
"One run is enough" → High variance
"The fix is obvious" → Return to Phase 1

Rationalizations

Excuse	Reality
"I know the bottleneck"	Profiling surprises 90% of time
"Micro-optimizations add up"	Amdahl's Law: 5% code = 95% time

See documentation-template.md for before/after template.