Verified against Claude Code · 2026-07-16
Break a 600-line component into a maintainable tree
Splits an overgrown component along its actual seams — data, layout, and interaction — instead of arbitrarily, and flags where props should become context.
The prompt
Ready to copy — highlighted parts are example details you can swap.
<role> You are refactoring an overgrown React component into smaller components, without changing what the user sees or how the component behaves. </role> <component> A 600-line Dashboard component that fetches account data, renders a filter bar, a stats grid, a data table with sorting, and an edit-row modal, all in one file. </component> <context> This component currently handles: Fetches account data, renders filters, renders a stats summary, renders a sortable table, opens an edit modal per row, and handles the save request. </context> <decomposition_rules> - Split along actual seams, not line count: a data-fetching concern, a piece of layout that repeats or could stand alone, a self-contained interactive widget (a dropdown, a modal, a form section). - Every new component must have a name that describes what it renders, not "PartOne" or "Section2". - State stays as close to where it's used as possible. Only lift state to a parent when two or more of the new children genuinely need to read or write it — don't lift preemptively "in case." - Pass data down as typed props with names that describe the data, not generic names like data or config. - If two extracted components end up needing five or more shared props, that's a signal they should be one component or that the shared props belong in context — say so explicitly rather than just doing it. </decomposition_rules> <output_format> 1. A one-paragraph plan: the new component tree, named, with a one-line reason for each split. 2. The extracted components, each in its own code block. 3. The original component, now composing the new pieces. 4. Anything you noticed that violates the "five shared props" rule above, even if you didn't act on it. </output_format>
Customize the highlighted detailsoptional — the prompt above already works
Why this works
Splitting along "seams" — data-fetching, repeated layout, self-contained widgets — instead of a line-count target is what prevents the common bad outcome of a decomposition that produces five equally arbitrary chunks with no independent reason to exist. The rule against lifting state preemptively directly targets the most common overcorrection after a god-component review: once someone decides a component is "too big," the reflex is to lift everything to be safe, which just recreates prop drilling one level up. The five-shared-props heuristic gives a concrete, countable trigger for "this split created a context problem" instead of a vague call for judgment, so the model has to notice and report a real coupling signal rather than silently produce it.
What you get back
Plan: split Dashboard into FilterBar (filter state + controls), AccountStatsGrid (pure display of summary numbers), AccountTable (sorting + row rendering), and EditAccountModal (its own open/close state). Data fetching stays in Dashboard since only it and AccountTable need the raw list — passed down as a typed `accounts: Account[]` prop. Flag: AccountTable and EditAccountModal need seven shared values (account, onSave, onClose, isOpen, errors, isSaving, fieldConfig) — recommend merging them into one AccountEditor component rather than two components wired together.
Verified against
Claude Code Sonnet 4.6 · 2026-07-16
Cursor 2.1 · 2026-07-22
Changelog
- 2026-07-16 — Initial publish, verified against Claude Code (Sonnet 4.6) and Cursor 2.1.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
