Review before git

So your agent just dumped a long plan.md in the terminal. Forty pages of rollout steps, risks, and "obvious" next moves. You want a second set of eyes before anyone runs it. The familiar move is to git add the plan, open a PR, and call that review.

I have done that more times than I want to admit. It feels responsible. GitHub's comment UI is good. Notifications work. Your teammate already lives there. If the file is not worth committing yet, you just made review wait on git. You also taught the team a habit: commit when you need attention, not when the work is ready.

What you actually need is a live link while the file is still moving. That is the whole job of this post. Before git. Not instead of git.

The early-PR trap

The trap is understandable. Line comments are good. Diffs are good. So people stretch "ready for history" backward until "I need a comment box" equals "open a PR." That stretch is the problem.

Here is the scene I keep seeing. It is Tuesday afternoon. The agent is mid-migration plan. Cutover section is still a sketch. You ping your lead: "can you look?" They say they are on a phone in an Uber. You could wait. You do not. You commit plan.md, open a draft PR, and paste the link into Slack. Done. Review has begun. Except it has not.

By the time they finish three threads, the agent has rewritten the cutover section twice. Their comments are about a paragraph that no longer exists. Diffs fight the live file. Someone tries to "resolve" a comment by editing through the PR flow while the agent still owns the file on your disk. CI may wake up for a markdown document that should never have triggered it. Threads attach to SHAs that stop matching anything real.

We spent the next morning reconciling chat, PR, and disk. The PR was not review. It was a messaging bus with a commit tax.

That is what early PR actually costs when the agent is still rewriting. Reviewers get pinged for a document that will change before they finish reading. You get a false sense that the plan is "in review" when it was never ready for the log. And the habit leaks. Plans are not the only thing people will force into git just to unlock a comment box.

What people try instead

Wait until it is commit-ready, then open a PR. Correct for finished work. Leaves the pre-commit gap empty. Waiting is honesty about git. It is not a review workflow for a moving plan.

Slack paste. Fast interrupt. Frozen snapshot. No live file. No @agent on the moving plan. You trade GitHub ceremony for paste ceremony and still lose the source of truth. Your teammate comments on yesterday's plan while the agent rewrites today's.

Screenshare. Fine for two minutes of verbal nuance. Calendar tax. No durable line anchors. Nothing for the agent to pick up later unless someone retypes the conversation into a prompt. I have watched people do a twenty-minute Zoom just so one person could say "that rollback step is wrong," then lose the note in a transcript nobody opens again.

Solo skim, then commit, then hope. Quiet and common. The PR becomes the first place anyone else sees the plan, often after the agent has already executed parts of it. That is how "plan review" turns into archaeology. You are reading a document that describes work that already happened.

None of those are wrong tools. They are wrong moments. The early PR is the clearest wrong moment: using commit as a way to send a message.

The loop before the file earns history

Gander is live review for markdown an agent is still writing. The author keeps the file on their machine. A reviewer opens a short URL. Every save updates every open viewer. Comments sit on the rendered page, like Docs. Comments that start with @agent come back into the session that owns the file.

gander watch plan.md

That command is hosted watch. It publishes a https://gander.md/s/… link and pushes on every save. It is not the local preview flag. Local gander plan.md --watch reloads a browser on your machine. It has no URL you can send and it cannot take comments. Mixing those two is the usual footgun. When you mean "someone else should read this while it moves," you want hosted gander watch.

Send the link. Do not wait for a PR.

Picture the Uber again. Your lead taps the link on their phone. They highlight a sentence about the cutover window. They leave a comment. You keep the session. They keep the tab. The agent is still writing on your disk. Their next save lands in the same view they already have open. No clone. No IDE seat. No draft PR pretending to be a chat room.

The reviewer does not need your IDE, your clone, or a seat in the agent session. They need a browser. Local file stays the source of truth. The hosted page is a live view plus threads, not a second repository and not a wiki fork.

When someone means action, they start the comment with @agent. Install MCP once so the session hears it (gander mcp install), or fall back to gander comments. The agent edits the local file. The same link updates. Human-only threads stay human. That split matters: most comments are conversation. A few are instructions. Collapse those into one inbox and you either spam the agent or strand the humans.

I like the small awkwardness of typing @agent on purpose. It forces a choice. Are you talking to me, or are you giving the session work? Early PRs collapse that choice into "leave a review comment and hope someone notices."

Handoff is a feature

When the plan is commit-ready, open the PR. GitHub review is the right tool then. We do not replace it. We do not do "AI PR review." We sit in the gap before the file should be in git at all.

Handoff is intentional. Watch while the agent is rewriting. Stop watching when the file should become history. Open the PR for the review job git is good at: durable, post-commit, merge-shaped work. You commit the file you already reviewed, not a parallel draft that only existed to unlock comments.

That last part is the quiet win. The history you end up with is the plan people already argued about on the live link. Not a trail of "WIP plan v3 for comments" commits that existed only because GitHub was the only comment box in reach.

If the teammate only has a browser and the plan still is not commit-ready, send the live link first. If execute is the next risk, review before run. Those are sibling cuts. This one is narrower: do not mint a PR as a comment transport.

Commit is not a messaging bus

GitHub is for work you are ready to put in history. A still-moving plan is not that yet.

Treat the early PR as a tell. You are using commit as a way to send a message. Send the message on the live file instead. Then commit when the file earns a place in the log.

The agent can keep rewriting. Reviewers can keep commenting. The same link can keep updating. Git can wait until waiting is honesty, not avoidance. An agent is a bad co-author if the only review surface is a terminal, a local editor, or a pull request that does not exist yet. Give them a live link first. Git later.