code-review

Code Review

Review all changed files for reuse, quality, and efficiency

Review local git changes as a plan-constrained code review, not as a generic style pass. Treat the provided plan or spec as the contract and the current diff as the implementation under review.

Prioritize correctness, plan adherence, scope control, and evidence. Adopt a deliberately demanding posture: assume the change set is not ready until it proves otherwise. Do not drown the report in empty cosmetics, but do surface debatable design concerns, sharp judgment calls, and “this feels wrong” observations when they could materially improve clarity, simplicity, maintainability, or future safety.

Required Inputs

• Obtain the plan first. Accept any of:
  • plain text in the prompt
  • repository file paths
  • links to sprint plans, specs, or design docs
• If the plan is missing or inaccessible, say that a plan-aware review cannot be done yet and request the missing plan material. Do not silently downgrade to a generic review.
• Determine scope before reviewing:
  • staged only
  • unstaged only
  • both staged and unstaged
  • specific paths if the user narrowed scope
• Separate explicit requirements, non-goals, constraints, and optional future ideas from the plan before reading the diff deeply.

Review rules

For each change:

1. Search for existing utilities and helpers that could replace newly written code. Look for similar patterns elsewhere in the codebase — common locations are utility directories, shared modules, and files adjacent to the changed ones.
2. Flag any new function that duplicates existing functionality. Suggest the existing function to use instead.
3. Flag any inline logic that could use an existing utility — hand-rolled string manipulation, manual path handling, custom environment checks, ad-hoc type guards, and similar patterns are common candidates.

Review changes for hacky patterns:

1. Redundant state: state that duplicates existing state, cached values that could be derived, observers/effects that could be direct calls
2. Parameter sprawl: adding new parameters to a function instead of generalizing or restructuring existing ones
3. Copy-paste with slight variation: near-duplicate code blocks that should be unified with a shared abstraction
4. Leaky abstractions: exposing internal details that should be encapsulated, or breaking existing abstraction boundaries
5. Stringly-typed code: using raw strings where constants, enums (string unions), or branded types already exist in the codebase
6. Unnecessary JSX nesting: wrapper Boxes/elements that add no layout value — check if inner component props (flexShrink, alignItems, etc.) already provide the needed behavior
7. Unnecessary comments: comments explaining WHAT the code does (well-named identifiers already do that), narrating the change, or referencing the task/caller — delete; keep only non-obvious WHY (hidden constraints, subtle invariants, workarounds)