Codebase Performance Optimizer

Two phases: Analyze then Optimize. Always show findings before touching code, unless user says "just fix it".

Phase 1 — Analyze

1. Map project: language(s), framework, build tool, package manager. view root dir, then relevant configs (package.json, webpack/vite config, tsconfig, etc).
2. Scan issue categories (grep/find via shell, or language-specific tools when available):
   • Duplication: repeated logic/blocks across files (near-identical functions, copy-pasted components).
   • Bundle size: heavy/unused deps, missing tree-shaking, no code-splitting, large barrel imports.
   • Images/assets: uncompressed images, wrong format (PNG where WebP/AVIF fits), oversized dimensions, missing lazy-loading.
   • Runtime perf: N+1 queries, unnecessary re-renders (React: missing memo/useMemo/useCallback, inline object/function props), blocking sync I/O, unindexed DB queries, O(n²) loops on large data.
   • Dead code: unused exports, unreachable branches, commented-out blocks.
   • Build config: missing minification, no compression (gzip/brotli), dev-only code shipped to prod.
3. Produce findings report (chat, concise): per issue — file:line, issue, impact (high/medium/low), proposed fix.
4. Ask user which categories to act on if list long, unless already said "fix everything".

Phase 2 — Optimize

Apply fixes incrementally, one category at a time, so changes stay reviewable:

• Dedup: extract shared logic into function/module/component; update call sites.
• Bundle: replace heavy deps with lighter alternatives (only if drop-in compatible), add/adjust code-splitting or dynamic imports, fix barrel-import issues.
• Images: recompress/convert via shell (cwebp, sharp, imagemin if available — check what's installed first), resize to actual display dimensions, add lazy-loading attributes.
• Runtime: memoization, batch queries, replace O(n²) with efficient structures/algorithms.
• Dead code: remove after confirming no external references (grep whole repo first).

After each category: run existing tests/build if project has them (npm test, npm run build, etc.) to confirm nothing broke. Report changes + why, file by file, short summary — not just "done".

Rules

• Never guess at "optimized" behavior that changes program output — perf fixes must be behavior-preserving.
• Don't install new deps for a fix if native/existing solution works.
• No test suite → flag it, proceed more conservatively (smaller diffs, manual reasoning about correctness).
• Very large repos → sample representative files/modules first, not blind full scan; ask user for subfolder if scope unclear.