optimize

name	optimize
description	Performance optimization workflow -- profile, identify bottlenecks, apply targeted improvements, verify gains
layer	hub
category	workflow
triggers	["/optimize","optimize this","make this faster","improve performance","reduce load time","this is too slow"]
inputs	[{"target":"Code, feature, page, or endpoint to optimize"},{"metric":"What to optimize for (latency, throughput, memory, bundle size, render time, etc.)"},{"baseline":"Current performance measurement (optional, will attempt to measure)"},{"budget":"Performance target/budget (optional)"}]
outputs	[{"profileReport":"Analysis of current performance with identified bottlenecks"},{"optimizations":"List of applied optimizations with measured impact"},{"beforeAfter":"Performance comparison showing improvement"},{"tradeoffs":"What was traded for performance (complexity, memory, readability)"}]
linksTo	["scout","test","code-review","refactor"]
linkedFrom	["cook","team","ship"]
preferredNextSkills	["test","code-review"]
fallbackSkills	["scout","research"]
riskLevel	medium
memoryReadPolicy	selective
memoryWritePolicy	selective
sideEffects	["Modifies source code files","May run performance benchmarks","May add caching layers or change data structures"]

Optimize Skill

Purpose

Systematically identify and resolve performance bottlenecks using a measure-first approach. This skill prevents the most common optimization mistake: guessing where the problem is and optimizing the wrong thing.

The law of optimization: Measure first. Optimize the bottleneck. Measure again. Repeat.

Never optimize based on intuition alone. Developers are notoriously bad at predicting where performance problems live.

Workflow

Phase 1: Define the Target

1. Identify what to optimize -- Be specific:

   • API endpoint response time
   • Page load / Time to Interactive
   • Database query performance
   • Build / bundle size
   • Memory consumption
   • Throughput (requests/sec, items/sec)
   • Render performance (FPS, re-render count)

2. Set the performance budget -- What is "good enough"?

   • If the user provides a target, use that
   • If not, use industry standards:
     • API: < 200ms p95
     • Page load (LCP): < 2.5s
     • Interaction (INP): < 200ms
     • Bundle size: < 200KB (initial JS)
     • Database query: < 50ms

3. Establish the baseline -- Measure current performance before changing anything. Record exact numbers, not impressions.

Phase 2: Profile and Analyze

4. Identify the profiling approach based on the target:

   Target	Profiling Approach
   API latency	Add timing logs, trace request lifecycle
   Database	Analyze query plans (EXPLAIN), check indexes
   Frontend load	Analyze bundle (webpack-bundle-analyzer), check network waterfall
   Render perf	Check component re-renders, identify expensive renders
   Memory	Heap snapshots, allocation tracking
   Build time	Build profiling, dependency analysis

5. Read the code in the hot path -- the execution path that matters for the target metric.

6. Identify bottlenecks -- Look for these common performance problems: