Your teammate shouldn't need your IDE

Agent plans live on your machine, in your session. The teammate who needs to look is often somewhere else: laptop on a call, phone, different desk. They should not need your IDE, your repo clone, or a seat in the agent session just to leave a comment.

Browser plus link. That is enough.

The job

You have a coding agent and a still-changing plan.md. You need a second engineer on it now. They are not in your session. They have a browser.

They are not in the agent session. That is fine. Send the live URL.

When to review relative to execute is a different post. This one is who can review without borrowing your setup.

The constraint is physical and social at once. The author has the session, the file, and the context. The reviewer has five minutes and a browser tab. If review tools ignore that split, they quietly select for people who can sit in the author's chair.

I keep meeting teams that say they "do plan review" and then describe a ritual that only works if the reviewer can join Cursor for twenty minutes. That is pairing. Pairing is useful. It is not the same as getting a second set of eyes on a moving plan while you keep the session.

What people do instead

Screenshare / pair in your IDE. High bandwidth once. Calendar tax. No durable line-anchored threads. The reviewer still needs access to your machine or session. Fine for "talk me through this paragraph." Bad for "leave three comments while I keep working."

"Just clone the repo." Full context, and friction. The still-moving local file is not on their machine. The agent session stays with you. If review requires a repo clone, you already lost the wedge. You also invent a sync problem: their checkout is not your live plan.md. I have watched people lose twenty minutes to "I pulled, which branch is the plan on?" while the agent kept rewriting the author's disk.

Invite them into the agent session. Same context as you. They need agent access and ceremony. Not browser only. Sometimes that is the right call. Often it is overkill for "does step four make sense?"

Slack paste. Interrupts now. Freezes a snapshot. You lose the live file. The teammate comments on yesterday's plan while the agent rewrites today's.

Early PR for review UI. Familiar. Also commits the plan so someone can use GitHub comments. Wrong timeline if the file is not commit-ready yet. The browser cut is simpler: the reviewer should not need your IDE even before git exists.

Each of those paths pulls the reviewer toward the author's setup. The useful direction is the opposite: pull the plan into a surface the reviewer already has.

The loop built for browser-only

Gander is live review for markdown an agent is still writing.

1. Watch: gander watch plan.md. Every save updates the hosted page.
2. Comment: they open the URL. Docs-style inline threads. No install. No IDE, no repo, no agent account.
3. Act: @agent comments land in your session via MCP. The agent edits. The same link updates.
4. Then: git when it is worth committing.

You keep the session. They keep a browser. Local file stays source of truth. Full loop is shipped.

gander watch plan.md

Hosted watch. Not local --watch. Local preview has no URL for them and cannot take comments. If your teammate is elsewhere, you want the hosted command.

gander watch plan.md → send link → they comment. You keep the session.

Notice what the reviewer does not get. They do not get your agent seat. They do not get write access to your disk. They get a live view and threads. Action still runs through @agent into the author's session. That is intentional. Browser-only review is not "everyone edits the same shared doc." It is "everyone can read and comment while the file still lives where the agent can change it."

Install MCP once on the author side so the session hears the summons. The reviewer still installs nothing. That asymmetry is the point. Ceremony stays with the person who owns the file. Participation stays cheap for everyone else. Before git, not instead of git.

Why the browser matters

IDE review sounds reasonable until you count the cost. Clone. Open. Find the file. Hope it matches what the agent just saved. Ask for a screenshare when it does not.

Phone review sounds unserious until you need a second opinion in a hallway between meetings. A link works. A clone does not. I have had a lead approve a risky ordering change from a grocery store parking lot because the link opened, the thread anchored, and @agent could act without them installing anything.

Async review sounds like a process document until you notice that most "quick looks" are async by default. The reviewer is not free the moment the plan lands. The live page waits. The Slack paste ages.

The browser is not a preference. It is the lowest common surface that still supports line-anchored threads on a moving file.

You can dress that up as accessibility or inclusion if you want. I mean it more bluntly. If the person whose judgment you need is not free to join your setup, and your review surface requires that setup, you did not "skip review." You filtered it out.

What this is not

Not a collaboration platform. Not a PM portal. Not "share markdown" as the product. Not a replacement for Slack or IDE pairing when those are the right tool for two minutes of talk.

Same product as the plan-before-execute post, different cut: the reviewer constraint.

It is also not "remove the author from the loop." The author still owns the session. The agent still edits the local file. The reviewer participates without becoming a second operator.

A filter you did not mean to build

Think about the last three people who should have looked at a plan. How many of them had your IDE open, your repo cloned, and time to join your agent session? If the answer is "one, maybe," your review process already filtered the other two out. Not because they lack judgment. Because the surface demanded your chair.

Browser-only review widens the set without widening write access. That is the trade. More readers. Same author. Same disk. Same agent session. Comments in, edits out through @agent when someone means work.

I want that to feel boring. Boring means it can become habit. Habit means the next plan gets a second set of eyes while changing it is still cheap.

Picture the filtered version again. You only ask the teammate who already has the repo open. They are busy. You wait. The agent offers to start. You let it. The people who would have caught the bad ordering were never in the room because the room required your IDE. Browser-only review is how you stop accidentally building that room.

Who gets a say

Requiring your IDE, your clone, or your agent seat is not a process preference. It is a filter on who can participate.

If review only works when the reviewer borrows the author's whole setup, you have already decided the answer: fewer people look, later, with more friction, after the cheap moment has passed.

Send the link. Keep the session. Let the teammate use the browser they already have. The plan stays on your machine. The review does not have to.