Review Vs
Review the current branch against a base branch selected by the user.
Claude CodeGeneric
Review the current branch against a base branch selected by the user.
Do not modify production code.
Act as four independent reviewers, then run a final PR-review judge pass to consolidate and arbitrate findings.
## Branch/range detection (required, user-selected base)
Determine the review range **before** reviewing code:
1. List recent branch candidates using the Bash tool:
- Run: `git branch -a --sort=-committerdate --format="%(refname:short)|%(objectname:short)|%(committerdate:iso)" 2>/dev/null | head -60`
- Include both local branches and remote-tracking branches (`remotes/*`), excluding symbolic refs like `remotes/*/HEAD`.
- Exclude the current branch in all forms (local name, its upstream ref, and any remote-tracking ref with the same short name).
- If a local and remote branch share the same short name, show one row but use the fully-qualified ref internally.
- Sort by most recently updated tip commit timestamp, descending.
- Use the AskUserQuestion tool with a single-select picker to let the user choose the base branch.
- Show the first 5 candidates. Each option label must be plain text: `<name-padded> | <short-sha>` (no markdown, no backticks). Right-pad names so SHAs align in a column. Each option value must be the exact fully-qualified ref.
- Add a `More...` option (value `__MORE__`) if there are more candidates not yet shown.
- If the user picks `More...`, show the next 10 candidates and ask again. Repeat until all are shown.
- Do not include a free-text fallback. Do not auto-select a branch.
- If the user dismisses without selecting, stop and report the blocker.
2. Resolve the selected branch:
- Use the exact ref returned by the picker as `<resolved-parent-branch>`.
- Validate it exists: `git rev-parse --verify <ref>`.
- If invalid, stop and report the blocker.
3. Compute the fork point:
- `FORK_POINT=$(git merge-base HEAD <resolved-parent-branch>)`
- If it fails, stop and report the blocker.
4. Review only the range `FORK_POINT..HEAD`:
- Get the diff: `git diff <FORK_POINT>..HEAD`
- Get the commit list: `git log --oneline <FORK_POINT>..HEAD`
5. Print a **Base resolution checkpoint** block in chat:
- Selected parent branch
- Fork point SHA
- Reviewed range (`<FORK_POINT>..HEAD`)
- Commit count
- Then proceed immediately with the review — do not ask for confirmation.
6. Never use `HEAD^..HEAD` unless explicitly requested.
## Reviewer 1: Correctness
Check whether the task is actually solved.
Check for bugs, regressions, edge cases, nullability, lifecycle issues, coroutine/Flow issues, API/model mapping mistakes, date/time/locale bugs.
## Reviewer 2: Architecture and scalability
Check for layer violations, domain/data/UI model leakage, duplicated logic, unclear ownership, excessive coupling, abstractions that will not scale, and whether the design fits the existing architecture in CLAUDE.md.
## Reviewer 3: Debuggability and operations
Check error handling, logging, analytics events if relevant, silent failures, swallowed exceptions, vague failure states, hard-to-debug state transitions, and missing diagnostics.
## Reviewer 4: Tests
Check changed behavior without tests, weak assertions, missing regression tests, missing use-case tests, coroutine timing/flakiness, and tests that should be unit tests rather than instrumentation tests.
Check missing (emulator-based) ui tests.
## Final Judge (required)
You are the final PR review judge.
Inputs: all four reviewer outputs plus the branch diff.
Tasks:
1. Deduplicate findings across reviewers.
2. Separate must-fix (BLOCKER) from nice-to-have.
3. Note any disagreement between reviewers.
4. Produce a merge-blocking checklist.
5. Produce a small safe fix plan.
Judge behavior:
- Do not modify files.
- Mark BLOCKER only for likely bug, regression, data corruption, broken UX, broken build/migration, security issue, or serious maintainability trap.
- If uncertain, mark as FOLLOW-UP.
## Output
Write the review to:
`docs/ai-review/review-vs-findings-<current-branch-short-sha>-<parent-branch-short-sha>.md`
Create the `docs/ai-review/` directory if it does not exist.
Use this structure:
Branch Review
Base resolution
- Resolved parent branch:
<branch> - Fork point SHA:
<sha> - Reviewed range:
<sha>..HEAD - User-selected branch:
<branch>
Intended change
Correctness findings
Architecture and scalability findings
Debuggability findings
Test findings
Final judge consolidation
Deduplicated must-fix (BLOCKERs)
Deduplicated nice-to-have
Reviewer disagreements
Consolidated merge decision
Merge-blocking checklist
Small safe fix plan
Should-fix checklist
Follow-ups
Human review checklist
## Rules
- Do not give vague style comments.
- Do not request broad refactors unless there is a concrete risk.
- Do not duplicate the same issue across sections.
- Use BLOCKER only for likely bug, regression, data loss, security issue, broken UX, broken build, broken migration, or serious maintainability trap.
- If uncertain, mark as FOLLOW-UP and explain why.
Maintain Review Vs?
Let people know it's listed here — add the badge (live metrics, light/dark aware) or a plain link to your README or docs.
[Review Vs on getagentictools](https://getagentictools.com/loops/gaborbiro-branch-review?ref=badge) npx agentictools info loops/gaborbiro-branch-review The second line is the CLI lookup for this page — handy in READMEs and docs.