---
name: review-change
description: Review a working tree, commit, branch or pull request for introduced behavioral defects. Use for evidence-backed code review in any language, including changes spanning repositories.
---

# Review a change

Resolve the target first. For a PR, compare the merge base to its exact head. For local work, inspect staged, unstaged and relevant untracked files. Identify intended behavior, supported callers and any explicitly deferred work. Treat the PR description as a statement of intent and check it against the implementation.

Read applicable project instructions and the root REVIEW.md when present. For a PR, use the base revision's review rules and review changes to those rules as part of the patch. When no context file exists, infer the contract from callers, tests and shipped interfaces. If a companion repository matters, identify the supported revision and record any unavailable evidence.

1. **Map the change.** Follow each meaningful hunk from its entry point to the observable effect. Inspect direct callers, persisted data and affected consumers. For generated code or configuration, follow it into the system that executes it.
2. **Choose realistic starting states.** Compare old and new behavior for inputs the system actually supports. Where relevant, trace an existing installation, missing or empty data, cancellation after selection, partial writes, retries or overlapping requests. Identify the party that owns the state at the time of use.
3. **Try to disprove each candidate.** Check guards, caller normalization, transactions, version constraints and tests. Establish a reachable trigger, changed behavior and user-visible consequence. Check whether the same failure predates the patch. Keep it only if this change introduces or materially worsens it.
4. **Check the proof.** Read the assertions and the path they execute. Use focused, side-effect-safe checks where available. Record whether the conclusion follows from source, a test, or a runtime observation. Name missing environment or dependency evidence when it affects the verdict.
5. **Report findings first.** For each independent cause, give priority, changed file and line, trigger and consequence. State the smallest correction or test that would settle it. Rank by impact and reachability. Keep unresolved high-impact questions separate. Consolidate duplicates and skip style already enforced by project tooling.

If there are no supported findings, say so and name material coverage gaps. If the target changes, recheck affected paths against the new revision. A review request by itself authorizes analysis only.