Review Branch
Read-only review of a branch (and its PR, if one exists). Fetch, inspect in
isolation, form an opinion, report back. Never modify the branch, the working
copy, or anything remote — the user decides what happens next.
Contract
- No product commits, pushes, rebases, or edits to the user's checkout. Only
disposable isolation metadata and its verified empty working-copy change may
be created and removed.
- No PR writes: no comments, reviews, labels, thread resolutions.
gh/API reads, local builds, and tests are fine.
Workflow
- Fetch & isolate. Run
jj status first. The user is often editing
locally at the same time, so don't disturb their checkout:
- jj: use
$jj, fetch with jj git fetch --remote origin, then create
jj workspace add /tmp/review-<slug> --name review-<slug> -r '<branch>@origin' -m 'chore: isolate branch review'. Always pass -r;
omitting it creates @ beside the current working copy rather than on the
pushed branch.
- plain Git:
git fetch origin <branch>, then git worktree add /tmp/review-<slug> origin/<branch>.
Review the diff against the merge-base with the default branch, commits as
pushed — not the new empty workspace @ or whatever is currently in the
user's primary working tree.
- Pull PR context. If a PR exists for the branch (
gh pr list --head <branch>), read it — description, review comments, CI status often carry
intent the diff alone doesn't (gh pr view, gh api for comment bodies).
Read-only; never post.
For a jjpr stack, use $jjpr only for read-only jjpr status <top> context;
never submit, merge, or watch.
- Review the code. Read the actual implementation, not just the diff
hunks. Judge correctness, API shape, fit with surrounding patterns and
sibling implementations. Run builds/tests in the isolated checkout when
they'd change the verdict. For depth, follow
$github-deep-review.
- Triage existing comments. For each unresolved review comment (bot or
human), check it against the code as pushed and classify: real (with
evidence), stale (already addressed — say where), or wrong (why).
- Report. Verdict first, then findings with
file:line refs, comment
triage, and concrete suggestions ranked by importance. State clearly that
no changes were made.
- Clean up. In jj, capture the temp workspace's name, root, and change ID;
verify its diff is empty; forget it from a surviving workspace; abandon only
that captured disposable empty change; then remove the exact directory. In
plain Git, remove the temp worktree. If anything is worth keeping, do not
remove it; report its exact path.
Stop after the report. Apply fixes or reply to comments only on explicit
go-ahead.
1---2name: review-branch3description: Read-only review of a branch or PR from origin in an isolated workspace or worktree — investigate, triage review comments, report; no changes.4---56# Review Branch78Read-only review of a branch (and its PR, if one exists). Fetch, inspect in9isolation, form an opinion, report back. Never modify the branch, the working10copy, or anything remote — the user decides what happens next.1112## Contract1314- No product commits, pushes, rebases, or edits to the user's checkout. Only15 disposable isolation metadata and its verified empty working-copy change may16 be created and removed.17- No PR writes: no comments, reviews, labels, thread resolutions.18- `gh`/API reads, local builds, and tests are fine.1920## Workflow21221. **Fetch & isolate.** Run `jj status` first. The user is often editing23 locally at the same time, so don't disturb their checkout:24 - jj: use `$jj`, fetch with `jj git fetch --remote origin`, then create25 `jj workspace add /tmp/review-<slug> --name review-<slug> -r26 '<branch>@origin' -m 'chore: isolate branch review'`. Always pass `-r`;27 omitting it creates `@` beside the current working copy rather than on the28 pushed branch.29 - plain Git: `git fetch origin <branch>`, then `git worktree add30 /tmp/review-<slug> origin/<branch>`.31 Review the diff against the merge-base with the default branch, commits as32 pushed — not the new empty workspace `@` or whatever is currently in the33 user's primary working tree.342. **Pull PR context.** If a PR exists for the branch (`gh pr list --head35 <branch>`), read it — description, review comments, CI status often carry36 intent the diff alone doesn't (`gh pr view`, `gh api` for comment bodies).37 Read-only; never post.38 For a jjpr stack, use `$jjpr` only for read-only `jjpr status <top>` context;39 never submit, merge, or watch.403. **Review the code.** Read the actual implementation, not just the diff41 hunks. Judge correctness, API shape, fit with surrounding patterns and42 sibling implementations. Run builds/tests in the isolated checkout when43 they'd change the verdict. For depth, follow `$github-deep-review`.444. **Triage existing comments.** For each unresolved review comment (bot or45 human), check it against the code as pushed and classify: real (with46 evidence), stale (already addressed — say where), or wrong (why).475. **Report.** Verdict first, then findings with `file:line` refs, comment48 triage, and concrete suggestions ranked by importance. State clearly that49 no changes were made.506. **Clean up.** In jj, capture the temp workspace's name, root, and change ID;51 verify its diff is empty; forget it from a surviving workspace; abandon only52 that captured disposable empty change; then remove the exact directory. In53 plain Git, remove the temp worktree. If anything is worth keeping, do not54 remove it; report its exact path.5556Stop after the report. Apply fixes or reply to comments only on explicit57go-ahead.
ci