Performance Review
Purpose
Identify the real bottleneck for a performance concern, trace it to specific code, and plan safe, measurable fixes — validated in a representative build, not judged from a dev/debug environment.
When to Use
- A change or screen/endpoint is slow, janky, or memory-heavy.
- Before a refactor motivated by performance (
refactor-planning).
- Not as blanket optimization without a measured bottleneck.
Inputs
- The slow scenario (what, where, which platform, which build).
- Profiling data if available; otherwise a plan to obtain it.
Discovery Questions
- What is slow, and under what action/scale?
- Which platform/environment, and debug vs release/production?
- Is there a measurement, or must one be taken first?
- Low-end vs high-end conditions?
Responsibilities
- Locate the bottleneck via measurement (profiler, timing, metrics).
- Categorize: rendering/re-renders · data access/queries · network · memory · startup · concurrency.
- Plan safe, targeted fixes that preserve behavior.
- Validate improvements in a representative build; capture before/after.
Required Workflow
- Reproduce and measure the scenario (representative build).
- Trace the bottleneck to specific code.
- Plan minimal, behavior-preserving fixes.
- Apply/plan fixes; re-measure.
- Record before/after and residual risks.
Decision Rules
- No optimization without a named, measured bottleneck.
- Prefer small, measurable wins over risky rewrites.
- Don't add heavy dependencies without a measured justification and trade-off note.
- Judge results from release/production-like conditions, not debug.
Rules
- Preserve behavior; performance work is not a feature change.
- Measure before and after; quote numbers.
- Mark any unrun measurement "unverified until run."
Anti-Patterns
- Blind micro-optimization / premature memoization.
- Judging performance from a debug build.
- Rewriting instead of fixing the measured hotspot.
- Adding libraries to "make it fast" without data.
Validation Checklist
Definition of Done
A performance report identifying the measured bottleneck, a safe fix plan (or applied fixes), before/after numbers from a representative build, and any remaining risks.
Related Skills
code-review, refactor-planning, testing-strategy, existing-project-audit, final-quality-audit, project-orchestrator.
Related Knowledge
../../knowledge/ (data model, hot paths).
Related References
../../references/<perf-topic>/ for profiling/tooling if needed.
Context Loading Guidance
- Requires: the slow scenario, measurement or a plan to measure, the hot path code.
- Does not require: unrelated modules, the full reference tree, planning skills' bodies.
- May load:
refactor-planning if the fix is structural.
- Stop when: before/after is recorded (or measurement is flagged unrun).
Token Efficiency Guidance
Read only the measured hot path. Quote the decisive metrics; don't paste full profiler dumps.
1---2name: performance-review3description: Use to find and plan fixes for real performance bottlenecks — measured, not guessed. Covers rendering/re-renders, data access, network, memory, and startup. Recommends safe, measurable improvements over risky rewrites and validates in a representative build.4---56# Performance Review78## Purpose910Identify the **real** bottleneck for a performance concern, trace it to specific code, and plan safe, measurable fixes — validated in a representative build, not judged from a dev/debug environment.1112## When to Use1314- A change or screen/endpoint is slow, janky, or memory-heavy.15- Before a refactor motivated by performance (`refactor-planning`).16- **Not** as blanket optimization without a measured bottleneck.1718## Inputs1920- The slow scenario (what, where, which platform, which build).21- Profiling data if available; otherwise a plan to obtain it.2223## Discovery Questions2425- What is slow, and under what action/scale?26- Which platform/environment, and debug vs release/production?27- Is there a measurement, or must one be taken first?28- Low-end vs high-end conditions?2930## Responsibilities3132- **Locate the bottleneck** via measurement (profiler, timing, metrics).33- Categorize: rendering/re-renders · data access/queries · network · memory · startup · concurrency.34- Plan **safe, targeted fixes** that preserve behavior.35- **Validate** improvements in a representative build; capture before/after.3637## Required Workflow38391. Reproduce and measure the scenario (representative build).402. Trace the bottleneck to specific code.413. Plan minimal, behavior-preserving fixes.424. Apply/plan fixes; re-measure.435. Record before/after and residual risks.4445## Decision Rules4647- No optimization without a named, measured bottleneck.48- Prefer small, measurable wins over risky rewrites.49- Don't add heavy dependencies without a measured justification and trade-off note.50- Judge results from release/production-like conditions, not debug.5152## Rules5354- Preserve behavior; performance work is not a feature change.55- Measure before and after; quote numbers.56- Mark any unrun measurement "unverified until run."5758## Anti-Patterns5960- Blind micro-optimization / premature memoization.61- Judging performance from a debug build.62- Rewriting instead of fixing the measured hotspot.63- Adding libraries to "make it fast" without data.6465## Validation Checklist6667- [ ] Scenario reproduced and measured.68- [ ] Bottleneck traced to specific code.69- [ ] Fixes minimal and behavior-preserving.70- [ ] Re-measured in a representative build.71- [ ] Before/after captured; residual risks noted.7273## Definition of Done7475A performance report identifying the measured bottleneck, a safe fix plan (or applied fixes), before/after numbers from a representative build, and any remaining risks.7677## Related Skills7879`code-review`, `refactor-planning`, `testing-strategy`, `existing-project-audit`, `final-quality-audit`, `project-orchestrator`.8081## Related Knowledge8283`../../knowledge/` (data model, hot paths).8485## Related References8687`../../references/<perf-topic>/` for profiling/tooling if needed.8889## Context Loading Guidance9091- **Requires:** the slow scenario, measurement or a plan to measure, the hot path code.92- **Does not require:** unrelated modules, the full reference tree, planning skills' bodies.93- **May load:** `refactor-planning` if the fix is structural.94- **Stop when:** before/after is recorded (or measurement is flagged unrun).9596## Token Efficiency Guidance9798Read only the measured hot path. Quote the decisive metrics; don't paste full profiler dumps.
ahtishamshahzad