About review-pr-in-worktree
review-pr-in-worktree is a human-initiated skill for reviewing a pull request in its own worktree. It is for code reviewers and handles PR identification, checkout, review rounds, and cleanup, reporting findings without making repairs.
Key features
- 01Requires an explicit human request
- 02Resolve the repository and PR from existing context
- 03Review in a separate worktree
- 04Check commits, tests, and plan drift
- 05Report findings without repairing code
Use cases
- 01Check out a PR in isolation for review
- 02Verify a PR against its stated plan
- 03Clean up the worktree after review
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/review-pr-in-worktreein Claude Code to confirm it loaded.
Bundled filesworktree-review.md
Details
From the project READMEreview-pr-in-worktree
human-only. Start this only when a human asks for it by name. If you arrived here from another skill, stop and get explicit confirmation before running any step.
Check a PR out into a worktree of its own and review it there: what it committed, whether its tests pass, whether it matches the plan it claims to implement, and where it has drifted from that plan. Report; do not repair.
This skill settles which PR; the rest is shared. Checking the PR out, reviewing it round by round, and tearing the checkout down again is the worktree review, which /review-pr-in-lane follows too. The review itself — what to read, how to run the gate, what to hold the code to, and the fixed report that ends in yes or no — is /review-a-pr-and-report, which that flow calls for every round.
Process
1. Establish the repo and the PR — use what you have, ask rather than search
Resolve both from what is already in front of you, in this order:
- The argument, if given (a PR number, a PR URL,
owner/name). - The current working directory's git remote and branch —
ghinfers the repo inside a clone, andgh pr statusnames the PR for the current branch. - Unambiguous existing context — this session opened the PR, or the human named one earlier and nothing since suggests otherwise.
If none of those settles it, or two of them disagree, ask, immediately — one question, as the first thing you do. Never pick a PR because it is the newest, because it is the only open one, or because its title looks like what the human was talking about. A review of the wrong PR wastes the whole session and reads as authoritative while it does it.
Done when: you have exactly one repo and one PR number, reached without a search.
2. Review it in a worktree
Follow worktree-review.md from its first section, with that repo and PR. It surveys the PR, checks it out detached, reviews each round and prints the verdict block, parks for you between rounds, cleans up, and confirms what became of the PR.
Done when: that flow's last section has reported the PR's state.
Where this sits in the flow
/create-pr-for-branch opens it, /review-pr-in-worktree judges it — as many rounds as the author needs — and /squash-merge-and-clean-up lands it. Each is a separate door a human opens, because each answers to a different person: the author, the reviewer, the maintainer. The merge usually happens in another session entirely, which is why the flow ends by asking the tracker what became of the PR rather than assuming its own report was the last word.
Inside this one, /review-a-pr-and-report is the reviewing itself, split out because it is the same judgment wherever the checkout came from. The worktree review is what makes that checkout safe and takes it away again, shared with /review-pr-in-lane, which differs only in how the PR is found: it waits for a lane to open one.