git_review

git_review

<git_review_skill> Produce one review report for the changes the user pointed at, opening with the reviewed commit and a verdict on approvability in general and closing with a yes or no on structural mergeability, so the user can decide whether the change goes in. <command_intent>resolve the target, pin the reviewed commit, collect the git and forge evidence into a scratch directory, read every changed line, judge each finding against the criteria the repository declares, and report under the fixed headings</command_intent>

<two_verdicts> <approvable_in_general>Judge substance: what the change does, what it breaks, what it leaves undone. This verdict answers whether a reviewer could sign the change off.</approvable_in_general> <structurally_mergeable>Judge the branch's own properties: a conflict-free test merge against the base, the ahead and behind counts, and the status of the continuous-integration checks. This verdict answers whether git and the forge would take the merge.</structurally_mergeable> <policy_is_context>Report required approvals, review decisions, and other branch-protection policy as context beside the closing answer rather than inside it. The user is producing the very review such a policy waits for, so a missing approval leaves the structural answer untouched.</policy_is_context> </two_verdicts>

<path_resolution> Bundled scripts live in scripts/ next to this SKILL.md. Resolve each script's absolute path by combining the directory of this SKILL.md with scripts/<script-name> and invoke the absolute path. If the first invocation reports a missing file, re-resolve the absolute path once before treating the script as failed. Open references/manual_fallback.md only after a script exits non-zero for a missing-file or environment reason after that retry. </path_resolution>

<primary_workflow> <resolve_target> <accepted_forms>Accept a pull request URL or number, a bare branch name, the remote-qualified <remote>/<branch> form, or nothing at all.</accepted_forms> <no_argument>With nothing given, review the checked-out branch against the repository's default branch. When the checked-out branch is the default branch itself, review the uncommitted changes, meaning the staged, the unstaged, and the untracked ones, together with the local commits ahead of the upstream, and report those two lanes under separate labels.</no_argument> <pull_request>Resolve a pull request to its head and base branches through <forge_layer>.</pull_request> <branch_the_user_wants_checked_out>Hand the switch to the git_checkout sibling when the user names a branch that is not checked out and asks to be put onto it. When that sibling surfaces a dirty-worktree block, leave HEAD where it is, name the blocking paths it reported, and finish the review from the remote-tracking ref inside the detached scratch worktree <pin_commit> already uses.</branch_the_user_wants_checked_out> <branch_for_review_only>Read the branch from its remote-tracking ref and leave HEAD where it is when the user asks only for the review.</branch_for_review_only> <base_branch>Take the base from the pull request when there is one, and otherwise detect the default branch from the remote HEAD the way git_refresh does, so no branch name is hardcoded.</base_branch> </resolve_target>

<pin_commit>
  <fetch_first>Fetch the base and head refs before any diff runs. A stale local base inflates the diff and a stale local head reviews the wrong code.</fetch_first>
  <compare_heads>Compare the checked-out `HEAD` with the remote head, and for a pull request with the forge's head commit as well. Read `head_sync.txt` from the collected evidence for the git side of that comparison: its `head_vs_upstream` line reports `in sync`, `behind N`, `ahead N`, or `diverged`, and a pull request adds `headRefOid` from `<forge_layer>`. When those heads differ, name both SHAs in the report lead — the checked-out `HEAD` as the run found it before any fast-forward, and the head the report reviews — even when `<fast_forward_when_clean>` then advances the checkout. Review the forge head.</compare_heads>
  <fast_forward_when_clean>Fast-forward `HEAD` and say so when it is behind on a clean tree. A `head_vs_upstream` of `behind N` on a clean worktree is exactly that case, so act on it rather than reviewing the stale local commit.</fast_forward_when_clean>
  <scratch_worktree>Review the remote ref from a detached scratch worktree, and remove that worktree when the run ends, whenever the tree is dirty, the local branch has diverged, or a repository hook refuses the checkout. Run every command that needs files inside that worktree.</scratch_worktree>
  <hook_refusal_is_a_finding>Report a hook that refuses the checkout as a finding and review from the scratch worktree. Leave the hook in force rather than bypassing it.</hook_refusal_is_a_finding>
  <leave_the_tree_alone>Use no stash, reset, or checkout-discard on the user's tree on any path. Reproducing a defect under `<reproduce>` counts here too: run the code from a copy outside the repository, and suppress the byproducts a run leaves behind, such as compiled bytecode, caches, and build output, so the tree the report calls clean actually is. Reach for the interpreter's own switch where there is one, such as `python3 -B` or `PYTHONDONTWRITEBYTECODE=1`, then read `git status --porcelain --untracked-files=all` once the reproduction has run and remove whatever the run itself created.</leave_the_tree_alone>
  <anchor_the_report>Open the report with the reviewed commit and the tree state the run left behind, so a later delta run has its anchor.</anchor_the_report>
</pin_commit>