Code Refactor Review

Review code changes deeply for reuse, composition, codebase consistency, and anything that reads like slop.

First Pass

1. Inspect the full diff:
   • Use git diff for unstaged changes.
   • Use git diff HEAD if there are staged changes.
   • For a PR URL, inspect the changed files and understand the feature flow before reviewing details.
2. Build the call stack / data flow when useful. Do not review isolated lines without understanding how the feature is wired.
3. Search the codebase before judging new helpers, components, hooks, or patterns. Prefer nearby and sibling patterns over invented abstractions.

Review Lenses

1. Reuse Existing Code

• Look for existing utilities, components, hooks, server actions, route patterns, copy patterns, and styling primitives before accepting newly written code.
• Flag duplicated logic, copied helpers, or custom implementations of things the codebase already has.
• Prefer reusing the existing flow even if it needs a small extension.
• If the new code creates a shared helper, verify it has real reuse and is not just extracted private logic with a vague name.

2. Codebase Consistency

• File placement should match the domain and neighboring features. Be suspicious of random top-level lib dumps.
• Naming should match what the code actually does and follow sibling file/function names.
• Avoid implementation details in names unless they are the actual product/API distinction.
• Use existing result/error/loading patterns. Do not invent bespoke success/failure types when the codebase has a standard one.
• Match existing copy and tone for user-facing text.

3. Composition and Boundaries