Propose a decomposition plan for an oversized function, without applying it
Category: Refactor · Updated 2026-09-22 · Tools: Both
Use this on a function or file that's grown well past what's easy to review in one sitting, where you suspect it's doing several unrelated things but haven't mapped out what they are yet. Planning first avoids a large, hard-to-review diff landing before you've agreed on the shape. Medium usage for the planning step.
Full prompt
Read <function/file path> and identify the distinct responsibilities it's currently handling in one place — for example, input validation, the actual business logic, formatting output, and logging might all be tangled together. For each responsibility you identify, propose a name for a new function it would become, what it would take as input and return as output, and which existing lines would move into it. Note any shared state or side effects that would make the split tricky. Do not apply the split yet — show me the proposed decomposition and wait for confirmation. Once I approve, implement it on a new branch, run the full test suite after the split, and confirm behavior is unchanged before considering it done. Don't push.
Tips
- Reviewing the proposed names and boundaries before implementation catches a bad split (one that just moves the mess into more places) before it costs a full implementation pass
- Ask specifically about shared state and side effects — that's usually where a decomposition plan that looks clean on paper runs into trouble in practice
- Confirm test coverage exists for the function before starting; if it doesn't, add characterization tests first so you can actually verify behavior is unchanged after the split
Still waiting on a reset? See what to do when you hit the limit, or check Codex / Claude time since last reset.
Back to the prompt library · Subscribe: all-products feed