Team workflow

You get a drafted review waiting for each reviewer whenever GitHub requests their review, and a comment on the PR that is theirs to post. Your team’s process — who reviews, what branch protection requires, where the conversation happens — does not change. One click starts it:

docker compose --profile team up -d

(On a laptop, npx reviewstage does the same for one person.)

How a review request reaches you

1. Someone requests your review on GitHub, as they do today.
2. The PR appears in your To review tab. With the poller (the team profile, or the desktop app) that takes up to 3 minutes; with a GitHub webhook about 1 second. Both write the same queue, so a webhook changes latency, not behaviour. Requests to a GitHub team handle reach the queue through webhooks (expanded to signed-in members); the poller only finds direct requests to a login.
3. You open the PR, click Start review, and read the drafted findings when it finishes. A review is a full agent run on your Claude plan; you choose which PRs earn one.

phone · queue → PR → tick → Post

On a phone: the queue, a PR opened from it, two findings ticked, and Post tapped.

What stays exactly as it is

• CODEOWNERS and required reviewers. ReviewStage never changes who GitHub asks for. It drafts for the person who was asked.
• Branch protection. You post as a plain COMMENT review under your own GitHub account. Approve is a separate click and a separate request, also as you. GitHub sees a human review and a human approval, so “require approvals” and “dismiss stale approvals” work as before.
• The conversation. Comments land inline on the PR, in your words. A finding that an existing thread already covers is marked reply, and you can post it into that thread instead of opening a new one.
• Your identity. There is no bot account and no shared token. If a comment carries your name, you chose it. Security has the full model.

What the team sees

• Slack, Discord or any webhook. A card when your review is requested and another when the drafted review is ready; cards mention the reviewer and open the PR page. Point them at a private channel: the review-ready card carries the agent’s summary, which can quote code. Set-up in Notifications.
• Phone. Each reviewer can install the dashboard on their phone and turn on push for it; the queue, the findings and the Post button are the same app at phone width.
• Insights. Reviews, keep rate, agreement between reviewers, cycle time — across the team and per repository.

One install, many repositories

List them in REPOS, or set REPO_ALLOW_ORG=acme to accept any repository under the org where someone gets a review request. Each repository gets its own clone, its own learnings and, if you want one, its own team default skill and risk paths. On the desktop app, the Repositories page in the sidebar adds or removes watched repositories at any time. Details in Team mode.

What to tell the team

Three sentences are enough:

When GitHub asks for your review, a drafted review is waiting for you in ReviewStage; run it when you want one. Tick what is worth posting, edit anything, and post — it goes out as a normal comment from you. Approving is still your own click, as it is today.

What it deliberately does not do

• It never approves, never requests changes, and never blocks a merge. The agent’s verdict is shown to you as an assessment and nowhere else.
• It never posts on its own, on a schedule, or on push. Every write to GitHub is a signed-in person’s click with that person’s token.
• It does not run on every PR. A review costs real tokens on the reviewer’s plan, so it is click-to-run.
• It does not post as a bot or a shared identity. Per-reviewer runs are independent; findings two reviewers both raised with a different skill, model or effort are marked confirmed.

Rolling it out

1. Start with DRY_RUN=1 (the team install’s default). Reviewers run a few PRs they already reviewed by hand and compare.
2. Set DRY_RUN=0 and restart when the output is good enough to carry their names.
3. Add the Slack or Discord card so a request reaches people where they already are.
4. Drop the same complaint three times and ReviewStage proposes it as a team rule; accept it and every later review follows it. See Skills and learnings.