Tuicr Brings Full Code Reviews Into the Terminal

There's a specific kind of friction that terminal-native developers live with every day—the moment a code review lands and the browser has to open. Everything else is in the terminal: the editor, the git history, the diff, the commit. Then suddenly you're in a tab, reaching for a mouse, navigating a web UI designed for a different kind of developer. It's not a catastrophe. It's just a small, persistent irritant. The kind that accumulates.

Tuicr (officially pronounced "tweeker," though the DevOps Toolbox creator admits he can't quite commit to it) is a new terminal UI that tries to close that loop entirely. Not just prettying up diffs—that's well-trodden territory—but handling the full review lifecycle: inline comments, range comments, review state, and crucially, pushing all of it back to GitHub or GitLab as an actual, real, team-visible review.

That last part is the one that matters.

The Gap That Existing Tools Left Open

The DevOps Toolbox video opens by acknowledging a tool called Hunk, a diff TUI the creator had praised just weeks earlier. Hunk is genuinely good at what it does—syntax-highlighted diffs, Vim motions, a clean interface. But its comments stay local. "Once you want the review to live where the team lives," the video notes, "you hit a wall."

This is the design distinction that separates a diff viewer from a code review tool, and it's not a subtle one. Viewing diffs is table stakes. The review—the artifact your team depends on, the thing that blocks or unblocks a merge, the record of why a decision was made—has to exist somewhere shared. If your comments evaporate when you close the TUI, you haven't reviewed the code in any meaningful collaborative sense. You've just read it.

Tuicr appears to understand this distinction at the architecture level. It stores review sessions as JSON, organizes them around pull requests pulled directly from the platform, and exposes a :submit command that pushes the entire review to GitHub (via the gh CLI) or GitLab (via glab). The comments show up on the PR as first-class review comments, indistinguishable from ones left through the browser UI.

What the Feature Set Actually Looks Like

The basics: single binary, Vim motions, Git/JJ/Mercurial support (yes, Mercurial—apparently there are three of you), side-by-side or stacked diff views, syntax highlighting, and a config.toml for customization including themes, leader keys, comment type restrictions, and a Tuicr-ignore file for excluding files from review diffs. The Vim muscle memory transplants cleanly—:w to save, command mode, visual block marking for multi-line comments.

Comment types are tiered: note, suggestion, issue, and—this is the one that will get screenshots—praise. For when you want to acknowledge that yes, this function is actually elegant, and you want that acknowledgment to land in the PR where the author will see it. Color-coded by type throughout the interface.

The pull request tab is where Tuicr separates itself from the diff-viewer category. It pulls open PRs from the connected platform, lets you mark hunks as reviewed (folding them out of view), and maintains session state so you can return to a review in progress. The focus panel—a file tree with a comment summary—gives orientation that's easy to lose in long diffs.

One design choice worth noting: the review session JSON is machine-readable but not particularly human-friendly. The DevOps Toolbox creator flags this directly, observing that review list returns "a non-human readable JSON that doesn't seem like it's designed for daily use." That's not a bug, exactly—it points toward the other thing Tuicr is building.

The Agent Angle

Tuicr ships with a [skill.md](https://www.gitbook.com/blog/skill-md) file: a structured workflow document that teaches AI coding agents how to use the CLI to add and read comments in active review sessions. The framing in the video is precise about how this is supposed to work: "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."

The intended flow is human-first: you review the code, leave your comments, and then the agent layers its own observations on top—inline, in the same session, alongside yours. Not a summary paragraph at the top. Actual inline comments integrated into the review artifact.

The DevOps Toolbox creator tested this by asking the AI agent (Pied Piper, referred to as "Pi" throughout) to review code from scratch, and the results were mixed. When there's no active session, the agent just reviews locally and the comments don't propagate anywhere useful. The skill assumes a pre-existing session. "The skill, if you ask me, should make sure it's stopped right away if there's no session or better yet, created on its own," the video observes—a fair criticism of an early-stage feature.

What's interesting here isn't the current implementation, which is clearly rough around the edges. It's the design philosophy. Most AI code review tools produce a summary: a block of text, usually appended to the PR description, that reads like a moderately attentive intern wrote it after skimming the diff. What Tuicr is gesturing at is an agent that participates in the review as a reviewer—leaving typed, addressable, line-specific comments in the same format that human reviewers use. Whether that's better or worse than a summary is an open question, and probably depends on how good the underlying model is. But the interface contract is different, and interface contracts matter for how people actually use tools.

What Approaching a Thousand Stars Actually Means

The project is early. The video notes it's "closing in on a thousand stars," which in OSS terms means it's past proof-of-concept but nowhere near the accumulated trust that comes from a few years of production use. The maintainer background—kernel graduate, decade as a staff engineer at LinkedIn and Confluent—provides some signal about the project's likely trajectory and code quality. The "vibe-coded slop" assumption the video preemptively addresses is real: early Rust TUI projects with GitHub integration do attract that accusation regardless of quality.

"In times where code reviews are literally being questioned as a practice," the video argues near the end, "making your life easier and hassle-free by bringing them closer to the dev—removing excuses—is exactly the hero we deserve."

That's doing some work, but it's not wrong. There's a legitimate debate happening in some engineering cultures about whether formal code review is worth the latency it introduces—especially as AI-generated code volumes increase and review queues lengthen. A tool that reduces the friction of doing reviews is a different kind of intervention than a tool that automates reviews away. One strengthens a practice; the other substitutes for it.

What Remains to Be Seen

The GitHub CLI dependency is both pragmatic and limiting. gh and glab are solid CLIs with their own authentication ecosystems, so Tuicr gets a lot for free by building on top of them. But it also inherits their constraints, and teams that aren't already CLI-authenticated will hit setup friction before the main event.

The configuration surface seems thoughtful—TOML-based, documented, extensible. The Tuicr-ignore file for excluding files from review diffs is the kind of small, practical feature that reveals someone thought carefully about real workflows rather than demos. Teams with generated files or vendored code know exactly why this matters.

Whether the agent integration matures into something genuinely useful or stays a half-baked feature will probably determine whether Tuicr becomes a daily driver or a cool demo. Right now it's clearly the latter for most people—but the underlying concept, human and agent comments coexisting in a structured review session that surfaces on the actual PR, is the right problem to be solving.

The browser tab isn't going away for everyone. But for the developers who've already moved most of their workflow into the terminal, Tuicr is a credible answer to the last thing they had to leave for.

---

— Dev Kapoor, Open Source & Developer Communities Correspondent