optimize-codebase-performance

Optimize Codebase Performance

Optimize a measured critical path, not code that merely looks inefficient. Separate diagnosis and proposal from authorized implementation.

Trigger boundary

Use this skill for:

• profiling user-visible or system-visible latency, startup, throughput, or resource consumption;
• locating CPU, memory, GPU, database, network, I/O, bundle, or rendering bottlenecks;
• producing a reproducible performance proposal;
• implementing approved optimization batches and verifying comparable before/after results.

Do not trigger for:

• cleanup without a named performance path and metric;
• incorrect output, crashes, races, leaks, or regressions whose cause is unknown - use debugging-investigator first;
• dependency, runtime, schema, or platform migrations - use codebase-evolution-controller;
• general web, Flutter, or Expo production audits without a performance decision - use the relevant builder;
• deciding whether the integrated candidate can ship - use verification-and-release.

Required inputs

Obtain or state:

1. critical path and affected user or system outcome;
2. target metric and whether lower or higher is better;
3. representative workload, input shape, concurrency, and cache state;
4. environment, hardware, runtime, build mode, and dependency state;
5. success threshold, correctness invariants, and acceptable trade-offs;
6. available profiler, telemetry, benchmark, test, and operational evidence;
7. time, compute, production-safety, privacy, and cost constraints;
8. whether the user approved a previously proposed optimization batch.

If the target is vague, select the nearest observable path and metric but keep conclusions provisional until the user confirms relevance.

Safety baseline

• Inspect repository and environment state before measurement. Preserve uncommitted and unrelated user work.
• Treat profile, speed up, optimize, reduce, and improve requests as diagnosis and proposal authorization only at first.
• Do not edit repository or infrastructure files until the user separately approves a concrete proposal produced by this skill.
• Limit approval to named batches, files, settings, workloads, trade-offs, and verification. Re-propose materially different work.
• Prefer local, sanitized, read-only measurement. Do not upload private code, traces, profiles, or customer data without authorization.
• Do not run high-cost, destructive, production-load, permission-changing, or externally billable experiments without explicit authorization.
• Never trade correctness, security, privacy, accessibility, observability, or maintainability for an unproven or marginal gain.
• Never claim improvement from non-comparable measurements.