Code Structure Review

Review how the change is shaped: its abstractions, its control flow, where its logic lives, and how much a reader must hold in their head. Behavior stays exactly as it is.

Above all, be ambitious. Do not stop at local cleanup. Actively search for "code judo" moves: restructurings that preserve behavior while making the implementation dramatically simpler, smaller, more direct, and more elegant.

Rethink how to structure the implementation to meaningfully improve quality without affecting behavior. Improve abstractions and modularity, reduce spaghetti, improve succinctness and legibility. Be ambitious: where there is a clear path to a better implementation that means restructuring some of the surrounding code, say so. Be thorough and rigorous. Measure twice, cut once.

Target

Scope comes from $ARGUMENTS: a path, commit, range, branch, or PR number; empty means uncommitted changes plus the current branch's diff vs its base. For a single commit, compare against its first parent. Run git status --short first and do not report problems already fixed in the worktree.

Scope discipline. Report only what the change introduced or made load-bearing. Pre-existing structure is out of scope however bad it looks, and a nearby finding does not pull it in. Where pre-existing structure genuinely blocks the change from being clean, say so as a note, not a finding. Without this rule a repeated review re-raises the whole codebase every round.

Depth