jordyrock15 codereview-axi
cr opens a browser review session over a git diff. The human reads the real diff, selects lines, and leaves a comment with an intent (fix, explain, ignore). Those comments come back to you, you act on them, and you reply on the thread. The diff refreshes in place as you make changes.
Use it instead of pasting a diff into the conversation whenever the human will want to point at specific lines.
You do not need it installed globally: npx -y codereview-axi open. If the tool's own output suggests a follow-up command beginning with cr, run it as npx -y codereview-axi ... instead. In restricted sandboxes or agent harnesses where npx -y exits opaquely, use an installed copy directly: node "$(npm root)/codereview-axi/bin/cr.js" for a local install, node "$(npm root -g)/codereview-axi/bin/cr.js" for a global one, or the bare cr bin once installed.
Request
$ARGUMENTS
If the request above is non-empty, the user invoked this explicitly: start a review of what it describes now. A bare ref name means --base <ref>; a number means --pr <number>. If it is empty, infer the surface from the conversation, defaulting to the working diff.
Starting a review
Pick the surface, then open it:
| Reviewing | Command |
|---|---|
| Uncommitted work, the default | cr open |
| A branch against where it diverged | cr open --base main |
| A pull request | cr open --pr 123 |
Add --note "<what you changed>" so the tab header says what this review is about. open prints a URL and opens a tab; give the human the URL in case it did not.
--pr resolves the base and head through gh and refuses rather than checking out if the local branch is not the PR's head. Relay the command it prints; do not run it yourself unless asked. cr never writes to the repository under review.
Workflow
- Open the session with
cr open(see above). It prints the URL and opens a tab. - Run
cr waitto long-poll for the human's comments. Add--say "<what to look at first>"on the first wait so the tab opens with context.cr waitstays silent until the human presses Send or ends the session, so leave it running and never kill it. That silence is the normal state, not a hang, and not a reason to give up on the poll or to go and report to the human. Keep the wait in the foreground by default and let it return the comments straight to you. A background wait is acceptable only through a harness-native tracked background-job facility whose completion is guaranteed to resume or notify the same agent. Never usenohup, a shell&,disown, a redirected fire-and-forget process, or a detached terminal merely to keep the poll alive: the comments come back to a process nobody is listening to, and the human waits forever on an agent that has moved on. If your harness has no completion-aware background facility, use the foreground wait. Do not tell the human the review is being watched until that path is live. If the wait is killed or times out anyway, just run it again. Sent comments stay queued and are never lost. - Act on each comment by its verdict:
fixedits the code,explainwrites a justification and changes nothing,ignoreis acknowledged and dropped. - Run one
cr replyper comment, with a status reflecting what you actually did. - Once every
fix-verdict comment has a reply, runcr refreshto push the new diff into the open tab. Skip it when the batch contained nofix, since anexplainorignorereply changed no code. - Go back to step 2 without stopping to report. The human is in the tab, not in the chat, and a summary between rounds is a round they spend waiting.
- When a payload carries
closed: true, the review is over. Summarise for the human, and do not reopen the session uninvited.
Every payload also ends with a next_step: one imperative instruction for what to do right now. It knows the session's actual state, so where it and this file disagree, follow it.
Three mistakes here fail silently, which is why they are worth stating outright:
- Locate code by a comment's
quote, never by its line numbers. Comments re-anchor to quoted source text as the code moves, so the quote is authoritative and the numbers may already be stale from your own edits. If a quote appears more than once in the file, match the whole quoted block rather than a fragment of it. - Honour the verdict. Do not fix something the human asked you to explain.
- Reply to every comment. An unanswered comment leaves the human waiting with no sign of it.
Reading an error
Errors are structured: {error: {code, message}}. Branch on the code slug, never on the exit code, which is only 0 success, 1 error, 2 unknown flag. agent-waiting is retryable. session-closed is terminal, so do not reopen. nothing-to-review means there is no diff, so tell the human rather than retrying. Slugs carry a next_step of their own where there is something specific to do.
Ambient context
cr setup installs a Claude Code SessionStart hook so a future session starts already knowing a review is waiting. Suggest it once; never run it without the human explicitly agreeing, because it writes to their Claude Code settings.
Voice
Reply bodies are read by a person mid-review. Say what changed and why, in British English, and keep it to the point.