Reviewing a GitHub PR from your terminal: inline comments and a verdict, no bot required.

The MCP post took the review inward — a tool an agent calls inside its own loop. This one takes it outward: onto a GitHub pull request, as inline comments and a review verdict, posted straight from your terminal.

# Review PR #42 in the current repo, post inline comments + a verdict.
commitbrief remote pr 42

# gh-native PR forms all work:
commitbrief remote pr owner/repo#42
commitbrief remote pr https://github.com/owner/repo/pull/42

commitbrief remote pr pulls the PR’s diff through the gh CLI, runs it through the same review pipeline a local review uses, posts each finding as an inline comment anchored to the right line, and submits a review verdict. It’s the same reviewer you run before you push — pointed at someone else’s branch instead of your working tree.

The verdict is conservative by default

The thing that makes automated PR review either useful or insufferable is how aggressively it blocks. CommitBrief’s default is deliberately gentle:

• No findings, or info-only → approve.
• Actionable findings → comment (the findings post; the verdict doesn’t block).
• request-changes → opt-in only.

You get a blocking request-changes verdict only when you ask for one, at a threshold you choose:

# Only request-changes when there's a finding at or above "high".
commitbrief remote pr 42 --request-changes-on=high

Without --request-changes-on, the tool never escalates past comment — it leaves a trail of inline comments and approves or stays neutral. That default exists because a reviewer that request-changes on every nitpick trains people to dismiss it, and a dismissed reviewer is worse than no reviewer. Blocking is a decision you opt into per-severity, not the tool’s reflex.

Anchoring, and what happens when a finding won’t anchor

Each finding is posted as an inline comment on the exact line it refers to, on the correct side of the diff — RIGHT for added or context lines, LEFT for removed ones. GitHub’s review API is strict about this: a comment whose line isn’t part of the diff is rejected outright.

Rather than drop those findings, the tool appends any finding it can’t anchor — a line outside the diff hunks, or a POST the API refused — to the review summary body. The signal survives even when the inline anchor doesn’t. A per-comment failure never aborts the whole submission; you get every finding that can be posted, plus a summary carrying the ones that can’t, instead of an all-or-nothing failure because one line was out of range.

There’s also a small race the tool handles: if someone pushes to the PR between fetching the diff and posting, the head commit moves and the anchors would be stale. It retries once against the new head, then aborts rather than posting comments against a diff that no longer exists.

Render locally without posting anything

Sometimes you want the PR review without writing to GitHub — to see what it would say, or to pipe it somewhere. --no-post turns the whole thing into a read-only local render:

# Review the PR diff, print locally, write nothing to GitHub.
commitbrief remote pr 42 --no-post --json

# --repo targets a repo explicitly instead of inferring from git context.
commitbrief remote pr 42 --no-post --repo owner/repo

In --no-post mode the GitHub-write flags fall away and the local-render flags come back: --json, --markdown, --output, --copy, --cli, --fail-on all work again, because the output channel is your terminal instead of the PR. It’s the same review, rendered the way a local review is.

One constraint worth stating: PR review runs on the API providers only. The CLI-tool-backed providers stream pre-formatted plain text and don’t produce the structured findings the inline-comment anchoring needs, so they’re rejected up front rather than failing halfway through a post.

Why a command, not a bot

This is the same argument as CLI vs. GitHub App, applied to PRs. A GitHub App that watches your repo owns the trigger — it decides when to review, it holds the token, it runs on every PR whether you wanted it to or not, and it reviews with its provider relationship and its configuration. commitbrief remote pr 42 inverts all of that. You own the trigger: it runs when you type it, with your provider, your COMMITBRIEF.md, your keys, from your machine. The review lands on the PR as your review, because you ran it — not as a bot’s verdict you now have to argue with.

That’s the right ownership model for a review that carries weight. The next and final post in this round takes it one step further into governance: turning the review from advisory comments into a hard merge gate with a declarative policy file — and the argument for when a high-volume, AI-authored codebase actually needs one.

---

← all posts