Overhaul

Input

• A whole repository, platform, major subsystem, or long-running improvement program.
• Use explicit input first; otherwise infer from context, recent edits, selected files, or branch.
• Safest default: plan first and get user signoff before broad edits.

Workflow

1. Define the target. Identify goals, scope, constraints, non-goals, and whether behavior changes are allowed.
2. Baseline first. Find available commands and run safe checks where practical: tests, build, typecheck, lint, performance or deploy checks. Record failures before changing code.
3. Map the system. Identify entry points, core modules, data flow, external dependencies, deploy path, and docs that matter for the requested scope.
4. Find leverage. Rank issues by user impact, correctness risk, maintenance cost, performance impact, and confidence. Separate observed facts from guesses.
5. Propose a wave plan. Break work into reviewable chunks with explicit scope, validation, risks, and expected outcome for each chunk.
6. Get signoff. Before editing, ask the user to approve the plan and choose execution style: validate after each major chunk or proceed through the approved plan and report at the end.
7. Execute in chunks. For each approved chunk: inspect, edit narrowly, validate, document relevant changes, and summarize what changed.
8. Reassess between chunks. Pause for user validation when requested, when risk increases, or when the plan needs to change.
9. Close the loop. Re-run relevant checks, summarize completed work, behavior changes, docs changes, remaining risks, and follow-up work.