What this prompt does
This prompt turns the model into a React performance engineer and asks it to audit your component tree for wasted re-renders, then hand back a ranked, evidence-based fix list. Crucially, it bans premature memoisation — so instead of sprinkling useMemo and useCallback everywhere, it has to name the component, the exact trigger, why the render is unnecessary, and the specific fix. The structure forces reasoning over reflex.
The variables ground the audit in your real app. [framework] sets the React version and its rendering behavior. [state_libs] tells the model which tools it is allowed to reach for in fixes — a Context-plus-Zustand setup invites context splitting and store selectors, where another stack would not. [tree_description] is the heart of it: you paste your component tree and state sources, and the model maps each finding to where it sits in that tree, so the output is about your code, not a textbook example.
When to use it
- You profiled a React app and want a structured list of what to fix first
- A broad context provider is re-rendering large subtrees on every change
- Props that change identity each render are forcing children to re-render
- You want fixes ranked by render reduction, not a flat dump of suggestions
- You want to avoid scattering
useMemo/useCallbackand hiding the real cause - You need an explicit note on what was deliberately left alone and why
Example output
The model returns a ranked table with columns for component, trigger, reason, fix, and expected render-count delta. Each row ties a finding to a place in the tree you pasted, names the state, context, or prop change that triggers it, and prescribes a concrete fix like a context split or a store selector. A closing note calls out anything it intentionally did not touch to avoid premature optimization.
Pro tips
- Paste a real, labeled
[tree_description]with the state sources marked; the audit is only as good as the tree you give it - Set
[state_libs]accurately so the fixes use tools you actually have — it will suggest selectors for Zustand or context splitting for Context as appropriate - Keep the no-premature-memoisation rule; needless memo hooks add cost and mask the real culprit
- Ask for the expected render-count delta per fix so you can verify against the profiler afterward
- Start at the top of the ranked table — the highest-delta fixes usually trace back to one over-broad context
- If a fix surprises you, ask the model to explain the trigger chain before applying it rather than trusting the table blindly
- When a fix is a context split, confirm the new contexts map to how the data actually changes, so you are not just moving the re-render somewhere else
- Re-run the audit after applying the top few fixes; clearing the loudest culprit often reveals a second tier of renders that was masked before
