Open-source project
persiyanov/herdr-reviewr avatar
persiyanov/herdr-reviewr

persiyanov/herdr-reviewr: a review pane that sends comments back to your coding agent

A code review + file viewer sidebar for herdr. Comment on a diff and send back to agent. Inspect diffs, files, and a PR state.

719 stars77 forksRustMIT

At a glance

What is it?
herdr-reviewr is a Rust terminal pane for herdr that shows an agent's diff, lets you comment on lines, and sends those notes to the agent's input. It is read-only by design, and the Send path only works inside herdr.
Who is it for?
Adopt herdr-reviewr if you already run herdr on macOS or Linux and want line comments to reach the agent's input without leaving the terminal. Skip it if you are on Windows, or if you expect a review tool that can post to GitHub, GitLab or Azure DevOps: the PR tab is read-only.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly Rust, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The gap herdr-reviewr fills between an agent's diff and the chat

An agent edits files in a worktree and reports back in a chat pane. The human half of that loop is reading the diff and saying what is wrong with it. In a plain terminal that means running git diff, scrolling, and then retyping the criticism into the agent's prompt by hand, file by file.

herdr-reviewr is a herdr plugin that puts the diff in a pane next to the chat. The README describes it as a code-review pane for herdr: your agent writes the code, you read its diff in a pane beside the chat, comment on the lines, and send the notes back. The target user is someone already working inside herdr with an agent, on macOS or Linux, who wants line-level comments to arrive in the agent's input rather than in a scratch file.

The scope is deliberately narrow. The pane never edits the worktree and, per the README, sends nothing on its own. Comments are collected and sent when you press the send key. That constraint is what makes it usable next to a live agent: nothing in the review pane can change the code under review.

One pane, three tabs, four diff scopes

The pane is pointed at a git worktree and has three tabs. Changes shows the active scope's changed files with plus and minus stats and totals in the header. All files shows any file's current content from the whole worktree, with comments included; a collapsed folder containing a changed file shows a dot, and ignored paths are dimmed. PR is a read-only mirror of the branch's pull request or merge request: state, checks, description and comments, rendered as markdown.

Diff scopes are the part that maps onto agent workflows. Uncommitted is the working tree against HEAD, covering staged, unstaged and untracked files. Branch is the working tree against the merge-base with the base branch, so it includes uncommitted work plus the branch's commits; the base is the repository's default branch until you pick another. Last turn is everything that changed in this worktree since its most recent turn started, which is the scope that matches an agent that works in turns. Commits lets you pick which commits to review.

Search is powered by fff-search, and the Cargo.toml shows neo_frizbee as the matcher behind the fuzzy ranking, with the same rule used to rank branch names in the base picker. Syntax highlighting comes from syntect, configured with parsing, regex-fancy, dump-load and plist-load, and the comment in Cargo.toml notes the choice of a pure-Rust regex engine and prebuilt syntax dumps rather than loading YAML at runtime.

Installing the herdr plugin and reviewing a first diff

The README gives a plugin install that pulls prebuilt binaries, so no Rust toolchain is required. The plugin id used by the action command is persiyanov.reviewr, which is not the same string as the GitHub repository name; the README calls this out in the keybinding example.

bash
herdr plugin install persiyanov/herdr-reviewr

To open the pane in the current workspace, invoke the plugin action. The action id is open and the plugin id is persiyanov.reviewr.

bash
herdr plugin action invoke open --plugin persiyanov.reviewr

reviewr also auto-opens when herdr creates a workspace for a worktree, whether the checkout is new or opened from disk. Setting auto_open = false keeps it hidden until you ask for it.

If you want a keybinding, the README shows a herdr user config entry with a plugin_action command. Note the comment in the snippet: the command uses the plugin id, not the display name.

toml
[[keys.command]]
key = "cmd+r"
type = "plugin_action"
command = "persiyanov.reviewr.toggle"

A first review run follows the quick start. Pick a file in the navigator and the diff follows; j and k move, and the ] key walks the changes hunk by hunk across files. Tab switches panes. Press v, extend the selection with j and k or by dragging the gutter, then c to comment and Enter to save. Press s to send every comment to the agent's input. The footer shows the next step, and ? lists every key that works in the current context.

Outside herdr, the same binary runs as a plain terminal app against a repository path. The README states that everything works except Send and the last-turn scope, which need herdr around.

bash
herdr-reviewr ~/some/repo

Where herdr-reviewr is the wrong tool

The requirements list is short and strict: herdr 0.7.5 or newer for the plugin system, git on PATH, a truecolor terminal with Unicode box-drawing, and macOS or Linux. Windows is not supported. The PR tab additionally needs gh, glab, or az with the azure-devops extension, authenticated, though the other tabs do not.

The larger limitation is what the PR tab does. It is a read-only mirror. reviewr never writes to the forge, so you cannot approve, request changes or post a review comment to GitHub, GitLab or Azure DevOps from this pane. If your workflow ends with a review submitted on the pull request, this tool only covers the reading half; the submission still happens elsewhere.

The last-turn scope is the one to test on your own setup. The README points its readers at the limitations section for that scope, and the definition of a turn lives in herdr, not in reviewr. If your agent's turns do not line up with how you think about a unit of work, the uncommitted and branch scopes are the more predictable choices.

It is also not a general git client. There is no staging, no committing, no conflict resolution, and the README states the pane never edits your worktree. Anyone who wants to act on a diff inside the same tool is looking at the wrong project.

herdr-reviewr against a plain terminal diff viewer

The obvious alternative is what most people already do: git diff in one terminal split, or a pager such as delta, plus the agent's chat in another. That approach has no dependency on herdr, works on Windows, and covers any repository the shell can reach. Its cost is the loop. Review notes are typed into the agent's prompt as prose, with no line anchoring, no per-comment list, and no way to jump back to the comment you left on line 42 of a file you have since scrolled past.

herdr-reviewr trades that portability for structure. Comments are attached to a line or a range, navigable with n and N, listable with l, and sent as a batch. Text selection and copy work with the mouse, and the pane can search the whole worktree by fuzzy file name or live code grep. None of that exists in a pager.

The dependency is real, though. Send and the last-turn scope require herdr, so the tool's main advantage disappears outside it, and the README's fallback mode is explicitly reduced. A pager also handles repositories that are not worktrees managed by herdr, which this pane does not.

Version cadence, licence and what upgrading costs

The repository is MIT licensed, and the Cargo.toml declares edition 2024 with rust-version 1.97, so building from source requires a recent toolchain. Prebuilt binaries avoid that entirely for normal use.

The release history shows a fast cadence: v0.37.0 and v0.37.1 on 2026-09-13, then v0.38.0 on 2026-09-16, matching the last push on 2026-09-16. The version is still below 1.0, and a patch release landing three days after the previous minor is a sign that interfaces and behaviour are still moving. Treat upgrades as something to check rather than assume.

Upgrading is a reinstall. The README's update path uninstalls the plugin and installs it again, and notes that your config is keyed by plugin id and survives the round trip. There is no documented rollback procedure in the README, so if you pin a working version, keeping the previous release binary is a decision you have to make yourself. The justfile shows the maintainer's own local workflow for swapping binaries during QA, including a qa-restore task that restores the release binary the last qa-install replaced, but that is a development convenience, not a documented upgrade path for users.

For contributors, the justfile mirrors CI with fmt-check, lint and test, and the Cargo.toml forbids unsafe code while enabling the pedantic clippy lint group. The MIT licence places few obligations on users; it also means no warranty, and nothing here is legal advice.

Editorial conclusion

Adopt herdr-reviewr if you already run herdr on macOS or Linux and want line comments to reach the agent's input without leaving the terminal. Skip it if you are on Windows, or if you expect a review tool that can post to GitHub, GitLab or Azure DevOps: the PR tab is read-only. Before relying on it, verify that your herdr version is at least 0.7.5, that git is on PATH, and that the last-turn scope behaves in your worktree, since the README's limitations section is where that scope is qualified.

Frequently asked questions

What is herdr-reviewr and who is it for?

It is a code-review pane for herdr that shows an agent's diff, lets you comment on lines or ranges, and sends those comments to the agent's input. It is aimed at people already working with an agent inside herdr on macOS or Linux.

How do I install herdr-reviewr?

The README gives a single plugin install command, herdr plugin install persiyanov/herdr-reviewr, which uses prebuilt binaries and needs no Rust toolchain. To open it, invoke the open action for the plugin id persiyanov.reviewr.

Does herdr-reviewr work without herdr?

It runs as a plain terminal app when you point a release binary at a repository path, but the README states that everything works except Send and the last-turn scope. Those two features need herdr around.

Can herdr-reviewr post my review comments to GitHub or GitLab?

No. The PR tab reads GitHub, GitLab or Azure DevOps and renders state, checks, description and comments, but the README says reviewr never writes to the forge, so it never posts.

Official sources

  1. Issues
  2. License: MIT
  3. persiyanov/herdr-reviewr on GitHub
  4. README
  5. Releases
Community notes

Community notes