Refactor

@<file> has repeated logic in <functions>. Extract a shared helper without changing behavior. Keep the public API identical, and run the tests to confirm nothing broke.

List every file that needs the <X → Y> migration, and for each one describe the exact change. I'll then run you over each file with a scoped, tightly-permissioned command — for now, just produce that per-file plan.

Find all usages of <deprecated API or pattern> across the codebase and list them with file paths. Then propose a refactor plan in small, testable steps — don't change anything yet.

Fix <function> so it works correctly for all valid inputs. Implement the real logic that generalizes — do not hard-code values or special-case the tests just to make them pass.

Refactor <target>. Only make changes that are directly requested or clearly necessary — no new abstractions, no extra config, and no defensive code for cases that can't actually happen.

Rename <old> to <new> across the codebase. Update all references and imports, and don't touch any unrelated code. Show me the list of files changed.

Refactor <function> in @<file> for readability — early returns, clearer names, fewer nested branches. Behavior must stay identical; show me a before/after of the tricky parts.

@<file> is too large. Propose a split into cohesive modules with concrete names and responsibilities. Wait for my OK, then move the code and fix all imports.

Replace any/loose types in @<file> with precise types inferred from how the values are actually used. Don't change runtime behavior, and flag anything that reveals a real bug.

Look through the git history of <file> and summarize how its API evolved and why, before we refactor it. Flag any change that looks like it was made to fix a specific bug.