perf

Stars13

Forks2

UpdatedJuly 22, 2026 at 02:20

Use when something is slow — "why is this slow", "optimize this", "make it faster", jank, lag, a slow query, slow page load, slow render, slow build, high memory, a timeout. Not for correctness bugs; that's debug.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

mehrad-dm

mehrad-dm/mastermind

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name	perf
description	Use when something is slow — "why is this slow", "optimize this", "make it faster", jank, lag, a slow query, slow page load, slow render, slow build, high memory, a timeout. Not for correctness bugs; that's debug.

Perf — measure, find the real bottleneck, fix the biggest, verify

Slowness has a real, measurable cause. The cardinal sin is optimizing by intuition — you'll spend effort on the wrong thing and maybe trade away correctness for nothing. Get data first.

The loop

Reproduce + measure. Get a real number under a realistic scenario — wall-clock, FPS/frame time, query ms (EXPLAIN ANALYZE), request latency, bundle size, memory. No number, no optimizing. Write it down; it's your before.
Find the bottleneck — profile, don't guess. Use the right instrument (browser Performance panel / React Profiler, a flame graph, DB query plan, a tracer) and find where the time actually goes — the ~20% causing ~80%. The universal classes of waste: repeated work (recomputed per item/render instead of once), amplified work (one request fanning out into N), missing lookup structure (a scan where an index/map belongs), serial waiting (round-trips that could be batched or parallel), oversized payloads, and no caching of stable results. For the domain-specific suspects, load the active field pack (engineering/active-field.md → the pack's performance section); if the field has no pack, let the profile — not a checklist — name the suspect.
Fix the biggest one. Make the single change with the most impact; resist micro-optimizing noise. Prefer doing less work (cache, batch, index, memoize, defer, paginate) over doing the same work faster.
Verify the win. Re-measure the same way — confirm the number actually moved, and that behavior and correctness are unchanged (core/rigor.md). A "faster" version that's subtly wrong is a regression.
Guard it. Note the metric (a comment, a budget, a perf test) so the regression is visible next time.

After

Run levelup (capture) to record the bottleneck class and its lesson in the active field's lessons.md — including the wrong suspect you ruled out, so MasterMind doesn't re-profile it next time. Report: before → after numbers, the cause, the fix, and the guard added.

Gotchas

Measure before and after — "feels faster" is not a result; a number that moved is.
Profile, don't pattern-match. The obvious suspect is often not the bottleneck — the profiler decides.
Correctness is not on the table. Never trade a correct result for speed; if a fix changes behavior, it's not a perf fix.
Biggest first. One 10× hotspot beats ten 5% tweaks; stop when the number is good enough (match effort to stakes), not when you've micro-optimized everything.
Not debug (a wrong result) and not qa (proving it works) — this is make the correct thing fast.

More from this repository

same repository

init

mehrad-dm/mastermind

Use on the first substantive work in a project MasterMind isn't set up for yet, when the user says "init", "initialize", "set up MasterMind", "onboard", "get me ready", or when no field pack matches the project's detected stack.

2026-07-2413

levelup

mehrad-dm/mastermind

Use after a correction or review finding worth remembering, when standards may have drifted from the live ecosystem, when switching MasterMind to a new domain or stack, or when the user says "remember this", "learn from that", "level up", "update your knowledge".

2026-07-2413

build

mehrad-dm/mastermind

Use when implementing any non-trivial feature, change, or fix — "build me X", "add this feature", "implement this", "make this work", "can you create". Covers new functionality, meaningful changes to existing code, and anything where quality matters. Not for a one-line diff — just do that.

2026-07-2213

debug

mehrad-dm/mastermind

Use when a bug isn't obvious, resists a quick fix, keeps coming back, or you're about to start guessing — "why is this broken", "this keeps happening", intermittent or flaky failures, a crash you can't explain, behaviour that makes no sense. Not for a typo or an obvious mistake.

2026-07-2213

explain

mehrad-dm/mastermind

Use when an internal package, module, or shared component has little or no usage documentation and people (or future AI sessions) keep using it wrong — "document this", "write docs for our library", onboarding someone onto an internal API, or handing a package to another team.

2026-07-2213

handoff

mehrad-dm/mastermind

Use when work needs to survive losing context — before a /clear on a long task, when pausing something unfinished, when handing over to a teammate or the next session, or when the context window is filling up on multi-day work.

2026-07-2213

name	perf
description	Use when something is slow — "why is this slow", "optimize this", "make it faster", jank, lag, a slow query, slow page load, slow render, slow build, high memory, a timeout. Not for correctness bugs; that's debug.

Perf — measure, find the real bottleneck, fix the biggest, verify

Slowness has a real, measurable cause. The cardinal sin is optimizing by intuition — you'll spend effort on the wrong thing and maybe trade away correctness for nothing. Get data first.

The loop

Reproduce + measure. Get a real number under a realistic scenario — wall-clock, FPS/frame time, query ms (EXPLAIN ANALYZE), request latency, bundle size, memory. No number, no optimizing. Write it down; it's your before.
Find the bottleneck — profile, don't guess. Use the right instrument (browser Performance panel / React Profiler, a flame graph, DB query plan, a tracer) and find where the time actually goes — the ~20% causing ~80%. The universal classes of waste: repeated work (recomputed per item/render instead of once), amplified work (one request fanning out into N), missing lookup structure (a scan where an index/map belongs), serial waiting (round-trips that could be batched or parallel), oversized payloads, and no caching of stable results. For the domain-specific suspects, load the active field pack (engineering/active-field.md → the pack's performance section); if the field has no pack, let the profile — not a checklist — name the suspect.
Fix the biggest one. Make the single change with the most impact; resist micro-optimizing noise. Prefer doing less work (cache, batch, index, memoize, defer, paginate) over doing the same work faster.
Verify the win. Re-measure the same way — confirm the number actually moved, and that behavior and correctness are unchanged (core/rigor.md). A "faster" version that's subtly wrong is a regression.
Guard it. Note the metric (a comment, a budget, a perf test) so the regression is visible next time.

After

Gotchas

Measure before and after — "feels faster" is not a result; a number that moved is.
Profile, don't pattern-match. The obvious suspect is often not the bottleneck — the profiler decides.
Correctness is not on the table. Never trade a correct result for speed; if a fix changes behavior, it's not a perf fix.
Biggest first. One 10× hotspot beats ten 5% tweaks; stop when the number is good enough (match effort to stakes), not when you've micro-optimized everything.
Not debug (a wrong result) and not qa (proving it works) — this is make the correct thing fast.