review-branch

name

review-branch

description

Review the changes on the current git branch compared to its base branch on remote. Produces: (1) a summary of what the changes do, (2) issues and recommendations ranked by priority using 🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low severity, and (3) an overall quality rating. Use when the user says "review branch", "review my changes", "review this PR", "review the current branch", or wants a quality assessment before opening a pull request.

Review Branch

Review the changes on the current branch versus its base branch on remote.

Phase 1 — Determine Base

Find the merge-base so only commits unique to this branch are reviewed:

# Option A: use the upstream tracking branch
git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null
# → e.g. origin/main

# Option B: if no upstream, detect the default branch
git remote show origin | grep 'HEAD branch'
# → e.g. HEAD branch: main

# Find the common ancestor (exclude commits that landed on base after branching)
git merge-base HEAD <base-ref>
# → <merge-base-sha>

Use <merge-base-sha> as the comparison point for all subsequent commands.

Phase 2 — Gather Diff

git log <merge-base-sha>..HEAD --oneline        # list of commits
git diff <merge-base-sha>..HEAD --stat          # files changed + line counts
git diff <merge-base-sha>..HEAD                 # full diff

For large diffs (>500 changed lines), read file by file:

git diff <merge-base-sha>..HEAD -- <file>

Also read the full content of any new files that appear only in --stat but not in the diff (e.g. binary files, moved files).

Phase 3 — Produce Output

Output exactly this structure:

---

Summary

2–4 sentences: what the changes do, which components/systems are affected, and the stated goal (inferred from commit messages and code).

Issues & Recommendations

Omit any severity section that has no findings.

🔴 Critical

Bugs, security issues, data loss risks, broken logic.

🟠 High

Missing error handling for realistic failure paths, performance problems, missing tests for core logic.

🟡 Medium

Code quality, unclear naming, duplication, convention violations.

🟢 Low

Style, minor refactors, optional improvements.

Each finding:

• Location: file:line Problem: clear description of the issue Suggestion: concrete fix or alternative

Overall Rating

1–2 sentences: overall code quality verdict and whether the branch is ready to merge.

---

Tips

• Ignore formatting and whitespace changes unless they indicate a semantic problem.
• If commits reference issue numbers or ticket IDs, use them to infer intent.
• For test files, check coverage of the new/changed logic — missing tests on core paths count as 🟠 High.
• If the diff is empty (branch is up to date with base), report that and stop.