Refactoring

You own the contract. The structure changes. The behavior does not. Distinct from Feature, which adds behavior, and Bug fix, which corrects it.

If the cleanup reveals a missing feature or a real bug, record it as a follow-up. Changing that behavior needs its own authorized scope under implement or bug-fix. Preserve the current contract during the refactor. If a defect prevents safe delivery, report the blocker instead of shipping it.

For work spanning several PRs, use multi-phase-plan when a plan is needed. Keep an existing execution owner and shared store. For a pause or transfer, follow handoff.

1. Establish the behavior contract first. Use how over the affected subsystem, reusing prior grounding. Run existing characterization tests, snapshots, or an equivalence harness against the unchanged code. Add missing coverage before moving structure, following test behavior. Include relevant outputs, errors and their timing, side effects, and cleanup order. Type check and lint alone do not establish the contract.
2. Name the structure the code is missing per model the domain. Keep code whose structure is already clear and local. The reshape must remove complexity, not add indirection.
3. Name the target shape. State the intended module layout, types, and call graph using foundational thinking and redesign from first principles. For an unsettled design across function boundaries, use architect before the move. Reuse a settled design. Mechanical renames need no design competition.
4. Subtract before you add. Delete dead code, collapse one-caller wrappers, drop redundant validators, and remove orphan references within the agreed scope. Each deletion must preserve the recorded contract. Ship the smallest change that reaches the target shape under laziness protocol. Revert speculative cleanup that does not help.

5. Move in small steps, keeping characterization checks passing. For internal APIs whose callers are all in scope, migrate callers and delete the old API in the same wave. Preserve compatibility required by external consumers or a staged migration. Spot-check renames in code, strings, prose, and back-references.

   Delegate mechanical edits when available with specific paths, names, and behavior to preserve. Review the diff yourself. When delegation is unavailable, make a separate review pass.

   Apply no-comments to changed code and TypeScript guidance when relevant.

6. Prove behavior is unchanged on the real artifact. For larger reshapes, run an equivalence check over old and new outputs or replay a recorded baseline. Include the observable effects named in step 1. Use the project's verification skill or available tools on the interface the change affects. Inspect the evidence yourself. Missing or inconclusive verification is not a pass.
7. Confirm the change is worth keeping. The success measure is reduced reader load. If the diff does not lower reader load somewhere, revert only this attempt's changes, preserving unrelated work.
8. Keep small ordered commits under sequence verifiable units, with each behavior-preserving slice green before the next. Preserve commits already under review. For standalone work, use open-pr within the authorized delivery scope. When that scope stops short of a PR, such as a local-only request, run review-pr in fix-and-review mode instead. When used within an active execution workflow, whether inline or delegated, return verified results and follow that workflow's commit, review, and delivery instructions. Hardening, merging, and deployment require their own authorization.

Reply: the structure that changed, the preserved behavior, the equivalence evidence, what became easier to understand, and what shipped or was reverted.