welp is a quiet inbox for your GitHub review queue, and a tour of each pull request in the order it reads best.

It lives in your terminal. A first release candidate is out: the inbox reads your GitHub today, and the tour and posting come next. Install it with Homebrew.

welp at 160 columns. Left, the inbox grouped by state. Middle, stop 2 of 6 of a tour of acme/api #412, retry budget for the uploader: one budget covers the whole call, not each attempt. Right, the concept cards, five of eight marked. — A tour of acme/api #412, stop 2 of 6. From 160 columns the concept cards sit beside it.

what needs you

Review requests, the pull requests you opened, the issues and discussions that mention you. welp sorts them by what has happened since you last looked, not by anything you filed, onto four rungs.

Only the top rung has colour. Nothing blinks, nothing counts at you, and an item fades as it settles.

newsomething changed, and it is your turn
readingopened, not finished
waitingthe last word is yours
revieweddone, until someone pushes

The inbox at 120 columns: three new, three reading, one waiting, three reviewed. The selected new item, acme/api #412, previews its description and the latest comments. — The inbox. The first new item previews itself; the tour isn’t written until you open it.

the tour

Open a pull request and the agent reads it first. It hands you the stops in the order that makes sense, which is rarely the order git listed the files. Each stop says what changed and why it matters, names the lines it covers, and the concepts it touches. Its diff is one key away.

The dots beside an item are the tour: one per stop, filled to where you stopped, •••◦◦. Come back tomorrow and it opens where you were.

Stop 2 of 6 with its diff shown inline: the hunks of internal/retry/budget.go and do.go under the stop's title. — Stop 2 with its diff open, under the stop, not in another pane.

ask in place

A question goes under the stop it’s about: how this fits the code around it, whether it will hold under load, what the other way would look like. One agent session per pull request, so the follow-up remembers the question. Answers stay where you asked them, diagrams included, drawn in box characters.

cards, then one verdict

The tour proposes the concepts the change rests on. You mark each card as you go: fine, a question, or blocking, with a line of why. When you finish, the cards are the review body and you choose one verdict with it in view. Your own pull requests get the same tour and end with ready for review, or not yet.

The finish dialog for acme/api #412: Approve, Request changes and Comment, with Request changes selected because the cards say one blocking, one question, three fine. Under it, the review body the cards made. — The cards say one blocking, so Request changes is already selected. The body below is what gets posted.

sending is the confirmation

welp doesn’t ask whether you’re sure you meant to reply. The gesture that makes a write confirms it, and what is sent is exactly what you typed. Only what can’t come back asks twice.

write	confirmed by	and then
reply, comment	enter	a few seconds to edit or undo
react, resolve, mark an answer	a toggle	do it again to take it back
close or reopen an issue	it sends	u undoes it
post a review	the verdict	the body was in view when you chose
delete a commentlater	asks twice	the only dialog, and it starts on cancel

A review thread on internal/retry/budget.go line 42 after a reply was sent; the footer reads: replied to @alice on budget.go:42. — A reply, sent. The footer says where it went and offers to take it back.

yours, on your machine

welp signs in with the token gh already stored, so there is nothing new to create. Tours and answers come from the agent you already use, claude, codex, opencode or pi, run in a checkout welp keeps to itself; your own working copies are never touched.

What you read, asked and noted lives in one file on your disk. There is no welp server. Nothing reaches GitHub that you didn’t send.

where it stands

The first release candidate is out. Its inbox is your real GitHub, read with gh’s token, and it sorts itself the way this page says. The tour and the writes aren’t wired to the world yet: a pull request opens on its conversation, and a write says it can’t post.

Run it with -demo and the whole loop plays on a recorded GitHub and a recorded agent, which is where the pictures on this page come from. Next: the claude adapter and posting, then codex, opencode and pi, then a short tour of only what changed when someone pushes after your review.

try the release candidate

$ brew install --cask jrschumacher/tap/welp@rc

macOS and Linux, on Apple silicon, ARM and Intel. A candidate: things will move. When 0.1.0 ships, swap welp@rc for welp.