🧱 The wall every diff tool hits 0:20
The setup is a question rather than a feature list: what if you could review a pull request from the terminal, leave inline comments the way you would on GitHub, and then push those comments back to GitHub as a proper review — without opening a browser?
That last clause is the entire premise. The presenter had previously covered hunk, which gives a comparable diff experience, and names the limitation precisely: comments live in the tool. You cannot share them or push them. The moment you want the review to live where the team lives, you hit a wall.
The stated requirements are concrete: inline comments, range comments, review state, agent-friendly export, and those comments appearing on a real PR. The motivation is equally blunt — every AI-coded project now arrives with six changed files, four TODOs and a hidden helper function.
📦 What it is 1:44
tuicr — the presenter notes it is pronounced "tweaker" and audibly declines to keep saying it — is a single-binary Rust TUI built around reviewing and collaborating rather than around rendering diffs.
| Capability | Detail |
|---|---|
| Version control | git, jj (Jujutsu), and Mercurial |
| Comment types | note, suggestion, issue, praise — colour-coded, configurable |
| Comment scope | line, range, file-level, and review-level |
| Push targets | GitHub and GitLab, as real inline review comments |
| Export | Markdown to clipboard or stdout, for agents |
| Keybindings | Vim motions, command mode (:w, :submit, :diff) |
On the "vibe-coded" suspicion
The video pre-empts a predictable comment-section reaction to a young project: that it must be AI-generated filler. The rebuttal offered is that it is already sponsored by recognisable names and the author is an experienced staff engineer.
agavra/tuicr, written in Rust, MIT-licensed. The GitHub account belongs to Almog Gavra, registered since 2013, now listed as co-founder at Responsive — consistent with the "LinkedIn and Confluent, now doing his own thing" description.⌨️ Install and first run 3:40
Installation is a single curl and the binary is ready in any version-controlled project. The first screen lists locally available commits — including from other branches — and selecting one opens the diff viewer with syntax highlighting.
The presenter's assessment of the change highlighting is unusually specific: "best I've seen yet". Pressing ? opens the help menu.
| Command / key | Effect |
|---|---|
tuicr | Opens the commit list |
tuicr -w | Opens local working-tree changes for review |
| c | Add a comment (defaults to a note) |
| Shift+C | Add a file-level comment rather than line-level |
| r | Mark a file reviewed — folds it away |
| Tab | Toggle the focus panel: file tree plus comment list |
| y | Yank the whole review as markdown |
The mark-as-reviewed behaviour is the first thing that signals this is a review tool rather than a viewer: files collapse as you clear them, and you can reopen them to check again.
💬 Comments that have types 6:39
Tab and Shift+Tab cycle the comment type inline: note, suggestion, issue — each colour-coded, and the set can be extended or restricted in config. There is also a praise type, which the video jokes is for showing your "AI colleague" some love.
The yank behaviour is the detail worth stealing regardless of tooling. Pressing y copies the review as markdown, complete with a title and a framing line — "I've reviewed your code. Here are the comments. Please address them." — ready to paste straight into an agent.
Vim command mode covers the rest: :w or Ctrl+S saves the session to a path shown in the interface.
🚀 Submitting to GitHub 8:08
The payoff. A second tab in the interface pulls remote pull requests, so you can review a colleague's PR rather than only local commits. Then :submit opens the push menu with the review options you already know from GitHub.
gh) under the hood, and requires it installed and authenticated against the repository. GitLab works the same way via glab. On a locked-down corporate machine, that is the step to check before adopting this — the TUI is self-contained, the submission path is not.The presenter tests it honestly and reports the mismatch he sees: the comments do land on the real PR, but the general file-level comment does not appear quite as expected, which he suspects is a tuicr-internal comment type. The review itself submits correctly.
🔧 A real bug-fix workflow 8:46
Rather than stopping at the demo, the video runs the tool through an actual fix: a git worktree, an agent asked for a fix, review, submit, PR.
It also demonstrates composition with gh-dash — a TUI for GitHub project lifecycle — using its custom-actions feature to launch tuicr with a PR number directly from the dashboard. The division is clean: gh-dash for issues, notifications and PR lifecycle; tuicr for the code review itself.
One more layer appears: an OpenCode GitHub Action running as a second automated reviewer, adding the 👀 reaction and then approving with notes as a required second approver.
🤖 The agent skill, and its friction 10:48
tuicr ships an agent skill, and this section is the most useful in the video because it is where things do not go smoothly.
skills/tuicr/SKILL.md exists, alongside tuicr-wrapper.sh and tuicr-wrapper-zellij.sh — the tmux and Zellij split-pane integrations the video describes.The intended division of labour, quoted from the docs: the TUI is where the human reviews code; the CLI is how the agent discovers active sessions, reads user comments, and only when appropriate adds agent-authored comments.
Where it broke
Asked to review, the agent found no active session for the repository and simply performed a local review instead — silently producing the wrong thing. The presenter's critique is exactly right:
A second attempt — asking the agent to review his review — also did not work as planned, possibly requiring the comments to be submitted first. He says so plainly and invites others' experience rather than editing around it.
Also noted: tuicr review list returns JSON that is not designed for human reading. That is not a flaw — it is the machine-facing half of the interface — but it explains why the CLI feels unfriendly if you approach it as a person.
🎨 Layout and configuration 12:46
The presenter is candid that the stacked view is not his preference — fine when short on screen space, but he wants side-by-side, available via :diff. The file tree comes back with Tab, giving orientation and per-file status.
The feature he singles out is visual block marking: select a range and attach a multi-line note to a whole function or a section of one, instead of hunting for the signature line and hoping the reader infers the scope. For reviewing generated code — where the problem is usually a block, not a line — that is the right primitive.
Configuration lives in ~/.config/tuicr/config.toml: mouse on or off, theme, diff style, a customisable leader key, restricted comment types with custom colours, and a .tuicrignore file to exclude paths from review diffs.
🎯 The verdict, and the caveat 15:32
The conclusion is enthusiastic and appropriately bounded: tuicr is "the missing piece" — it pulls remote PRs, it submits reviews, and it stays. The closing framing is that in a period when code review is being questioned as a practice, removing friction removes excuses.
The honest summary: the diff viewing is good and the competition is close. The submit path is the differentiator, and it is real. If your reviews already happen on GitHub or GitLab and you would rather not leave the terminal, that is the whole case — and it is enough.
🔍 Claims checked
Verified against the GitHub API and the project's own README and source tree:
| Claim | Result |
|---|---|
| Single binary, written in Rust | Confirmed — agavra/tuicr, Rust, MIT licence |
| Works with git, jj and Mercurial | All three listed in the README support matrix |
| Pushes real inline reviews to GitHub and GitLab | Confirmed — and it is the only ✅ in that row of their comparison table |
Requires gh / glab CLI, authenticated | README: "Requires glab authenticated to the host" |
| Ships an agent skill with tmux / Zellij panes | skills/tuicr/SKILL.md, plus both wrapper scripts |
| Agent-ready markdown export | Clipboard or stdout, documented |
| Author is an experienced engineer, not a vibe-coder | Almog Gavra, GitHub since 2013, co-founder at Responsive |
| gh-dash for GitHub lifecycle | dlvhdr/gh-dash, 12,161 stars, Go |
| "Closing in on a thousand stars" | Now 1,289 stars, 126 forks, 85 open issues |
Star counts move. Repository state verified 28 July 2026.
💡 Key takeaways
- Reading a diff is the easy half. Most "terminal code review" tools are terminal diff tools. The review is the artefact your team needs, and it has to land where they are.
- The differentiator is one capability: submit. tuicr pushes real inline comments to GitHub and GitLab. On its own comparison matrix, that row is the only one where it stands alone.
- Comments are typed, not just text. Note, suggestion, issue, praise — colour-coded and configurable, at line, range, file or review scope.
- Yank-as-markdown turns a review into a prompt. y copies the whole review with file, line and type intact — structured feedback an agent can act on, rather than prose.
- Visual block marking is the right primitive for generated code. Attach a note to a whole function or block, instead of pinning it to a signature line and hoping scope is inferred.
- Submission depends on external CLIs.
ghfor GitHub,glabfor GitLab, both authenticated. The TUI is self-contained; the submit path is not — check this before adopting on a managed machine. - The agent skill failed silently, and that is the most useful moment in the video. With no active session it quietly did a local review instead of stopping. A checkable precondition went unchecked and produced plausible-looking wrong output.
- The CLI's JSON is not for you.
review listreturns machine-facing output by design — the TUI is the human surface, the CLI is the agent surface. - Three reviewers on one PR is now practical. Human in the terminal, agent via skill, and a CI model as a second gate. Different failure modes, same change.
- The author check holds. Rust, MIT, and a maintainer with a decade of staff-engineering history — worth confirming for any young tool you are about to put in your workflow.
- The star count has already moved past the video. "Closing in on a thousand" is now 1,289 — young, but no longer as unproven as described.
- The video is sponsored, and says so. The sponsored segment is unrelated and the tuicr coverage includes real criticism — but this is one reviewer's short-term experience, not a comparison.
🔗 Resources & links
- Tuicr Is Probably The Best Terminal Code Reviewer I've Ever UsedSource video — DevOps Toolbox, 16:14
- agavra/tuicrThe repository — Rust, MIT, 1,289 stars
- tuicr.devProject site and configuration documentation
- skills/tuicr/SKILL.mdThe agent skill — read this before wiring it into an agent
- dlvhdr/gh-dashGitHub lifecycle TUI — the complementary half of the workflow
- GitHub CLI (
gh)Required and authenticated for review submission