Code Review Workflow

Review changes without modifying code or publishing an external review. Respond in the user's language. A clear target authorizes immediate review; ask only when ambiguity materially changes scope or intent.

1. Resolve the target and version

Read Git operations before retrieving a diff. Record the requested scope, resolved commit IDs or index/worktree state, comparison base, and any path restriction.

• No target: include staged, unstaged, and untracked changes. If none exist, ask what to review; do not substitute HEAD.
• Explicit staged review: use index contents for both changes and surrounding callers, including unchanged files.
• Commit or range: use the selected revisions for context and consumers, never current worktree files as evidence of that revision's behavior.
• File paths narrow findings to those paths; follow necessary consumers outside that boundary for context and disclose the boundary.
• Distinguish endpoint comparison, merge-base comparison, and the legacy inclusive start~end notation. Do not silently change the base to make a command succeed.

Inspect status for unresolved conflicts and handle roots and merges explicitly. Preserve the user's index and working tree.

2. Inventory the change and explain intended behavior

Read requirements, relevant contracts, and before/after code in the selected versions. Establish what inputs should produce what observable results. A commit message is context, not proof of correctness.