Review Agent Code in a GitHub PR, lazygit or Hermes? What Each One Can't See
- Book: Ship It — the pragmatic startup tech stack
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
---
The agent runs for forty minutes and reports back: done. You open the diff. Fourteen files changed, one commit at the end, and somewhere in the middle a lockfile moved and a CI workflow gained a step.
Which of the agent's replies did that? Was it the one where you said "fix the test", or the one where it decided the test runner needed upgrading? The diff can't tell you. A diff knows files and lines. It doesn't know about turns.
Where you read an agent's work decides what you catch. This post compares three places: GitHub's pull request view, lazygit in your terminal, and the Review Desk in Hermes IDE. I build Hermes, so weigh the third section with that in mind. The PR view wins more of the comparison than you might expect from me.
Four questions for any review surface
Every review tool answers the same four questions, with different amounts of detail.
1. Granularity. What is the smallest unit you can look at on its own: the branch, a commit, a hunk, or the agent turn that produced the change?
2. Feedback. When you find a problem, how does your comment get back to whoever wrote the code, and is that an agent or a person?
3. Risk signals. Does the tool point at the changes that deserve a second look, like a lockfile, a CI workflow or a secret?
4. Review to merged. How many steps between "this looks right" and the change sitting on your main branch?
With a human author, question 1 barely matters. A person commits in chunks that mean something. An agent often doesn't commit until the end, or commits whatever is on disk, so a single commit can hold a dozen turns of trial and error.
!Three lenses over one long diff: a wide lens covering the whole branch, a magnifier over a single hunk, and a row of numbered beads marking each agent turn
Branch, hunk or turn: the unit you review in sets what you can isolate.
GitHub's PR view: built for teams and CI
The pull request page is where team review happens, and nothing else in this comparison replaces it.
Granularity. Since a December 2025 public preview, the new "Files changed" page lets you "review all commits, a subset of commits, or a single commit" without leaving the page, with C opening the commit filter if single-key shortcuts are on. Inside that, GitHub's review guide has you go file by file and tick Viewed. If the file changes after you tick it, it is unmarked again, which matters when an agent keeps pushing. The floor is the commit. If the agent squashed ten turns into one commit, the PR shows one commit.
Feedback. You can comment on a line or a range, propose a suggested change, and submit the review as Comment, Approve or Request changes. Agents that live on GitHub read those comments. GitHub's Copilot coding agent responds when you mention @copilot on a pull request, and from the Files changed tab you can use Fix with Copilot on one comment or Add to batch for several. It "only responds to comments from people who have write access to the repository." Claude Code GitHub Actions does the same for @claude in PR comments and reviews, once the workflow is installed. If your agent runs on your laptop instead, the comment sits on GitHub and you carry it back to the terminal yourself.
Risk signals. This is where the PR view is hard to beat for a team. Protected branches can require a number of approvals, a review from code owners, and passing status checks, and can dismiss stale approvals when new commits arrive. For dependencies, dependency review adds a rich diff of manifest and lockfile changes to Files changed, with vulnerability and license data. The dependency review action that enforces it works on all public repositories; private ones need GitHub Code Security or Advanced Security.
One trap is worth checking in your repo. Files marked linguist-generated in .gitattributes are, per GitHub's docs, "hidden by default in diffs":
# .gitattributes
package-lock.json linguist-generated
That line is reasonable for humans, who rarely edit a lockfile on purpose. For an agent that might bump a dependency on its way to fixing a test, it folds away the line you most wanted to see.
Review to merged. It is slow next to a local merge, and on purpose: push, wait for CI, wait for a reviewer. That wait is the point when other people depend on the branch.
lazygit: hunks and lines, at terminal speed
lazygit is a terminal UI for git, and it is very good at the part of review that is about shaping changes.
Granularity. Its unit is the hunk and the line. Version 0.66.0, released October 5, moved staging into the main view: "press space to stage a hunk or range of lines." The same release added "Build custom patches directly from a commit's diff." You can also mark a commit "so that any other commit you select will be diffed against it" (README). The current release is 0.66.1, from October 11.
For agent work, that means you can pull a bad hunk out of a commit, stage the good half of a file, and split one huge commit into three that make sense. Neither of the other two tools edits history this directly.
Feedback. lazygit has no review comments. You read, you decide, and you type the feedback into the agent yourself. One bridge arrived in 0.66.0: "Open the selected diff line in the branch's pull request," so you can jump from a line in your terminal to the same line on GitHub and comment there.
Risk signals. None built in. It shows you everything at the same weight, so the lockfile looks like any other file. Its custom command system lets you add your own checks, but you write them.
Review to merged. Fast. Merge, rebase, squash, all on your machine with a few keys. Press z to undo the last action, but note the README's caveat: undo "uses the reflog," so it can't bring back working tree or stash changes.
Hermes Review Desk: by turn, before a PR exists
Hermes is a desktop app that runs coding agents such as Claude Code and Codex, each in its own terminal and its own git worktree (README). Its Review Desk works from a different unit: the agent's turn.
Granularity. Hermes saves every agent turn, so you can diff or restore any single turn, with undo (README). A strip under each session, labelled "Agent replies" since 2.3.1 (October 13, 2026), shows one chip per reply with the lines it changed; click one to see its changes or restore your files to that point. The Review Desk (⌘G, or Ctrl+Shift+G on Windows and Linux) shows changes by turn or by file. So you can find the reply that moved the lockfile and restore your files to the point before it.
Feedback. You leave line comments in the Review Desk, and Hermes sends a line comment "back to the agent that wrote it" (README). For an agent running on your own machine, neither of the other tools closes that loop for you.
Risk signals. The Review Desk shows changes with risk flags (README). That gives you a pointer to where to look first.
Review to merged. Land "commits, opens a pull request or merges locally in one step, into the branch the task started from, and can be undone" (README). Undo data for a landed task is kept for 14 days (release notes). Your own checks can decide when a task is done.
!Three small terminal windows, each with a robot silhouette, and a folded note flying back along an orange thread to the one terminal whose robot wrote the marked line
Each line comment is routed to the agent session that wrote that line.
The Review Desk is a single-person, local review. It has no approvals, no code owners, no required checks on a shared branch, and no CI history. Turn history exists only for sessions run in Hermes; a branch an agent pushed from somewhere else is just commits. In a task with extra folders, the replies strip tracks changes in the main project only (2.3.1 notes). And the turn view tells you which reply changed a line, not why the agent did it; you still read the transcript for that.
Side by side
| | GitHub PR view | lazygit | Hermes Review Desk |
|---|---|---|---|
| Smallest unit | Commit, then file | Hunk and line | Agent turn, then file |
| Comments | Line, range, suggestions | None | Line comments |
| Feedback to agent | @copilot, @claude (GitHub-hosted) | You type it | Sent to the agent that wrote the line |
| Risk signals | Code owners, required checks, dependency review | None built in | Risk flags on changes |
| Team review | Yes | No | No |
| Undo | Revert PR | z via reflog | Restore a turn, undo a landing |
| Where it runs | GitHub | Your terminal | Desktop app, your machine |
Use them in order
They don't compete as much as the table suggests. They sit at different points in the life of a change.
1. While the agent is still working, review by turn. That is when "restore to before turn 7 and tell the agent why" is cheap, and the comment reaches the right agent without a copy-paste. Hermes does this; so does reading git diff after every turn, if you have the patience.
2. Before you push, shape the history. If the result is one blob of a commit, lazygit's hunk staging and custom patches turn it into commits a teammate can follow.
3. Once others are involved, open the PR. Approvals, code owners, required checks and dependency review belong there, and they protect the branch from you as much as from the agent.
If you work alone on a side project, step 3 may be a formality. On a team, it isn't optional, and no local tool should pretend otherwise. Hermes's Land step can open the pull request for you.
Where do you review agent code today, and what slipped past you because of it? Tell me in the comments.
---
If this was useful
I build Hermes IDE: it is free to download, source-available under BSL 1.1, runs on macOS, Windows and Linux, and isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor. If reviewing by turn sounds useful, try it on your next agent task and star it on GitHub or open an issue when something doesn't match what I wrote here. If the PR-and-CI step is where your small team still improvises, Ship It covers the road from localhost to production: CI/CD, hosting, auth, payments and monitoring, picked for a team without a platform department.
1 reaction · 1 comment
Lazygit-ல் Git வேலைகள் எல்லாம் ஒரே திரையில் தெரிகின்றன. Stage, commit, rebase ஆகியவை விசைப்பலகையிலேயே முடிகின்றன. முதலில் எதை முயற்சி செய்வீர்கள்?
jesseduffield/lazygit
Instagram-லும் பின்தொடருங்கள்: instagram.com
4 likes · 1 repost · 470 views
⌨️ GitHub 好项目｜Lazygit
把 Git 常用操作放进终端界面：查看差异、按行暂存、整理提交，还支持交互式 rebase 和 worktree。
适合习惯键盘的开发者；需先安装 Git、理解提交与分支。MIT 许可，支持 Windows/macOS/Linux。
jesseduffield/lazygit
图：官方 README 演示截图 t.co
1 like · 35 views
I run a dozen Claude Code sessions at once. This tmux console tells me which one needs me
!15 seconds: status bar → picker → jump to the session waiting on you → switch account from the sidebar
TL;DR — claude-tmux-sessions is a small set of tmux tools for running many Claude Code sessions in parallel. It answers three questions I kept asking myself: which session is waiting on me, what is everyone doing, and what do I do when one account runs out of quota? MIT, tmux + bash + python3, driven by Claude Code hooks.
How I use Claude Code
Some context first, or the design will look odd.
I use two Claude accounts to push several projects forward at the same time:
- One account per project. Each account has a 5-hour and a 7-day usage window. If one busy project shares an account with the others, it stalls them too. With an account per project, each has its own quota.
- One session per role inside an account. Algorithms, backend, frontend, testing: one session each, so each context holds only its own part of the work and doesn't drift.
- I only make decisions. I don't watch any one terminal. I go over when a session needs a yes/no, or when it has finished and I should look at the result.
- Memory lives in files. Project rules, hand-off notes and a dev log are in the repository, so switching accounts or sessions loses nothing.
That adds up to a lot of sessions open at once, more than one person can watch. tmux only manages windows; it has no idea what the Claude inside each window is doing. Hence this.
Four pieces
!The whole screen: Claude on the left, its sidebar on the right, the status bar at the bottom
Status bar: who is waiting on you
!Status bar: four counts on the left, the window list with a state per window, CPU/memory/swap/disk on the right
Each session reports its state through Claude Code hooks, and the status bar counts them:
- ⏸ waiting for your confirmation (a permission prompt is open and Claude is idle) — the only state that rings and sends a notification;
- ✔ finished, and you haven't looked yet;
- ▶ running, nothing to do;
- ✓ finished, and you've seen it.
The four counts never move: a zero turns grey but keeps its place, so you can click from muscle memory. Click ⏸ to jump to the session that has waited longest; click ✔ to get a list of just the finished-but-unread ones:
!Clicking ✔: a picker with only the done-unread sessions floats up from the bottom
That list is a tmux 3.7 floating pane, not display-popup, which is why clicking anywhere outside closes it — display-popup swallows clicks outside its box.
Picker: what is everyone doing
!Picker: grouped by project, numbered rows, live preview of the highlighted session
prefix + g lists every session, grouped by tmux session (for me, one per project), with a live view of the one under the cursor. Every row is numbered; type the number to jump. It behaves like an inbox: visiting a session marks it read, and quiet ones fold away by default, so the list shows only what needs you.
Sidebar: everything about this one session
Every Claude gets a sidebar on its right that is about this session only:
- Every turn. What you said and the start of the reply. Click a turn and the main pane scrolls to that turn's final answer. Turns before a /compact fold into one line. It reads the transcript file, not the screen.
- Quota. Context, 5-hour and 7-day bars. Grey until something runs well ahead of an even pace.
- Buttons. git (with the count of uncommitted files), files, refresh quota, switch account, close.
The git and files buttons open lazygit and yazi floating over the right 60 % of the window, so the Claude on the left doesn't re-wrap; click outside and they're gone:
!lazygit floating on the right, showing the diff of what Claude just changed
Rule of thumb: global things go on the status bar, things about the current session go on the sidebar. The status bar is short on space, and this keeps both uncluttered.
Switch accounts: keep going when one runs out
Click ⇄ on the sidebar and the session exits, then comes back as claude --resume of the same session id under the other account. Same conversation, same context. There are guard rails: a session that is working is left alone; one with unsent text in its prompt is left alone (exiting would lose it); a window with agent-team teammates first gets a line typed to the lead asking it to wind the team down, and switches once they've exited.
Trade-offs I made on purpose
- Hooks, not screen scraping, for state. Sessions report their own state when it changes: accurate, no polling, no CPU. The screen is read only where there is no other way ("which turn is where", "is there unsent text").
- An inbox, not a dashboard. Things you've seen turn ✓ on their own and come back when that session does something new. Nobody maintains the list.
- Everything is clickable. I work mostly by voice and trackpad, so every segment and button takes a click. Keyboard shortcuts are there too.
- When in doubt, don't switch accounts. It skips and tells you why rather than risk losing anything.
The rest of my setup
The tmux console is one of four pieces. I also dictate almost every prompt with a push-to-talk voice tool (an LLM proofreads each transcript, and Claude adds the words it sees misheard to the vocabulary itself), and look back at usage and configuration in a local web dashboard. That's written up in docs/workbench.md.
Try it
git clone https://github.com/threedaycat/claude-tmux-sessions.git ~/projects/claude-tmux-sessions
~/projects/claude-tmux-sessions/install.sh --lang en
Then add one line to your tmux config, source-file ~/projects/claude-tmux-sessions/tmux/claude-tmux.conf, and put the status-bar segments into your own status line; the README walks through it.
Known limits, up front: I use it daily on macOS only (Linux is untested); you need a Nerd Font for the icons; and a few features read Claude Code's screen, so a Claude Code UI change may need a follow-up fix. Issues and PRs welcome.
Git without memorizing commands — LazyGit
Git without memorizing commands — LazyGit
LazyGit is a free, open-source terminal UI for git. Run one command inside any repo and you get panels for files, branches, commits and stash. Stage a hunk with space, drop to a single line when you only want part of it, and step through merge conflicts with the arrow keys — pick a side with space, take both with b, undo with z. Press c to commit with a message. Interactive rebase, cherry-pick, bisect, amend, worktrees, a commit graph and an undo command, all on keys. Free and open source (MIT), written in Go — 83,108 stars on GitHub.
jesseduffield/lazygit
#lazygit #git #terminal
2 likes · 86 views
🔥 [1 Repo Every Developer Should Know] lazygit: The Free Tool Taking Over GitHub! #shorts
Discover jesseduffield/lazygit: simple terminal UI for git commands
💬 Comment "LAZYGIT" below for the direct link, or grab it from the links below:
👉 Interactive Star History & Live Analysis:
githubrepo.cloud
⭐ Embed Live Verified Badges in your README:
githubrepo.cloud
🔗 Direct GitHub Repository:
jesseduffield/lazygit
📊 Repository Specs:
⭐ Stars: 82,912
🍴 Forks: 3,063
💻 Language: Go
📜 License: MIT
#shorts #lazygit #cli #git #terminal #linux #devops #commandline #sysadmin
18 views
Repo link: jesseduffield/lazygit
Runs 100% locally — nothing uploads. What paid tool should I replace next?
Stop Paying $69.00 for Tower Basic — This Free GitHub Repo Replaces It
Tower Basic costs $69.00 a year per user. lazygit is free, open source, and runs entirely on your own machine.
lazygit has 83,257 stars on GitHub and is licensed under MIT. Your data never leaves your own machine — nothing gets uploaded to anyone's cloud.
⭐ Repo: jesseduffield/lazygit
── SYSTEM REQUIREMENTS ──
Windows: Windows 10 or 11; install with winget or Scoop, or download the release binary (official docs) · No stated minimum; lightweight single binary · Git must be installed (Git for Windows)
macOS: macOS 10.12 or later for the release binary (official docs); or install with Homebrew or MacPorts · No stated minimum; lightweight single binary · Git (Xcode Command Line Tools or Homebrew git)
── WHAT YOU GET ──
• LINE STAGING
• INTERACTIVE REBASE
• CHERRY PICK
• COMMIT GRAPH
• UNDO
I post free open-source replacements for paid software every single day. If you're tired of subscriptions eating your budget, subscribe — there's a new one tomorrow.
Searching for: free tower git alternative, lazygit, terminal git ui, free git client, interactive rebase made easy, lazygit tutorial
#Shorts #lazygit #OpenSource #SelfHosted
Pricing shown is Tower Basic plan, $69 per user billed annually (Tower lists it as $5.75 per user per month, billed annually) = $69 per user per year, checked 2026-10-17. Prices change — verify before you buy.
1 comment · 4 views
the new lazygit release drops the separate staging panel, you just stage lines straight from the focused diff. not sure how long my muscle memory takes to catch up
github.com/jesseduffield/lazygit/releases/tag/v0.…
Git 变更太多，想在终端里直观看清楚？
lazygit 用交互式界面管理暂存、提交、分支和日志，减少频繁记命令的负担。适合学 Git 的开发者；重写历史前先检查差异。
jesseduffield/lazygit
#Git #开发工具
1 like · 69 views
Mentions
Review Agent Code in a GitHub PR, lazygit or Hermes? What Each One Can't See - Book: Ship It — the pragmatic startup tech stack - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- The agent runs for forty minutes and reports back: done. You open the diff. Fourteen files changed, one commit at the end, and somewhere in the middle a lockfile moved and a CI workflow gained a step. Which of the agent's replies did that? Was it the one where you said "fix the test", or the one where it decided the test runner needed upgrading? The diff can't tell you. A diff knows files and lines. It doesn't know about turns. Where you read an agent's work decides what you catch. This post compares three places: GitHub's pull request view, lazygit in your terminal, and the Review Desk in Hermes IDE. I build Hermes, so weigh the third section with that in mind. The PR view wins more of the comparison than you might expect from me. Four questions for any review surface Every review tool answers the same four questions, with different amounts of detail. 1. Granularity. What is the smallest unit you can look at on its own: the branch, a commit, a hunk, or the agent turn that produced the change? 2. Feedback. When you find a problem, how does your comment get back to whoever wrote the code, and is that an agent or a person? 3. Risk signals. Does the tool point at the changes that deserve a second look, like a lockfile, a CI workflow or a secret? 4. Review to merged. How many steps between "this looks right" and the change sitting on your main branch? With a human author, question 1 barely matters. A person commits in chunks that mean something. An agent often doesn't commit until the end, or commits whatever is on disk, so a single commit can hold a dozen turns of trial and error. !Three lenses over one long diff: a wide lens covering the whole branch, a magnifier over a single hunk, and a row of numbered beads marking each agent turn Branch, hunk or turn: the unit you review in sets what you can isolate. GitHub's PR view: built for teams and CI The pull request page is where team review happens, and nothing else in this comparison replaces it. Granularity. Since a December 2025 public preview, the new "Files changed" page lets you "review all commits, a subset of commits, or a single commit" without leaving the page, with C opening the commit filter if single-key shortcuts are on. Inside that, GitHub's review guide has you go file by file and tick Viewed. If the file changes after you tick it, it is unmarked again, which matters when an agent keeps pushing. The floor is the commit. If the agent squashed ten turns into one commit, the PR shows one commit. Feedback. You can comment on a line or a range, propose a suggested change, and submit the review as Comment, Approve or Request changes. Agents that live on GitHub read those comments. GitHub's Copilot coding agent responds when you mention @copilot on a pull request, and from the Files changed tab you can use Fix with Copilot on one comment or Add to batch for several. It "only responds to comments from people who have write access to the repository." Claude Code GitHub Actions does the same for @claude in PR comments and reviews, once the workflow is installed. If your agent runs on your laptop instead, the comment sits on GitHub and you carry it back to the terminal yourself. Risk signals. This is where the PR view is hard to beat for a team. Protected branches can require a number of approvals, a review from code owners, and passing status checks, and can dismiss stale approvals when new commits arrive. For dependencies, dependency review adds a rich diff of manifest and lockfile changes to Files changed, with vulnerability and license data. The dependency review action that enforces it works on all public repositories; private ones need GitHub Code Security or Advanced Security. One trap is worth checking in your repo. Files marked linguist-generated in .gitattributes are, per GitHub's docs, "hidden by default in diffs": # .gitattributes package-lock.json linguist-generated That line is reasonable for humans, who rarely edit a lockfile on purpose. For an agent that might bump a dependency on its way to fixing a test, it folds away the line you most wanted to see. Review to merged. It is slow next to a local merge, and on purpose: push, wait for CI, wait for a reviewer. That wait is the point when other people depend on the branch. lazygit: hunks and lines, at terminal speed lazygit is a terminal UI for git, and it is very good at the part of review that is about shaping changes. Granularity. Its unit is the hunk and the line. Version 0.66.0, released October 5, moved staging into the main view: "press space to stage a hunk or range of lines." The same release added "Build custom patches directly from a commit's diff." You can also mark a commit "so that any other commit you select will be diffed against it" (README). The current release is 0.66.1, from October 11. For agent work, that means you can pull a bad hunk out of a commit, stage the good half of a file, and split one huge commit into three that make sense. Neither of the other two tools edits history this directly. Feedback. lazygit has no review comments. You read, you decide, and you type the feedback into the agent yourself. One bridge arrived in 0.66.0: "Open the selected diff line in the branch's pull request," so you can jump from a line in your terminal to the same line on GitHub and comment there. Risk signals. None built in. It shows you everything at the same weight, so the lockfile looks like any other file. Its custom command system lets you add your own checks, but you write them. Review to merged. Fast. Merge, rebase, squash, all on your machine with a few keys. Press z to undo the last action, but note the README's caveat: undo "uses the reflog," so it can't bring back working tree or stash changes. Hermes Review Desk: by turn, before a PR exists Hermes is a desktop app that runs coding agents such as Claude Code and Codex, each in its own terminal and its own git worktree (README). Its Review Desk works from a different unit: the agent's turn. Granularity. Hermes saves every agent turn, so you can diff or restore any single turn, with undo (README). A strip under each session, labelled "Agent replies" since 2.3.1 (October 13, 2026), shows one chip per reply with the lines it changed; click one to see its changes or restore your files to that point. The Review Desk (⌘G, or Ctrl+Shift+G on Windows and Linux) shows changes by turn or by file. So you can find the reply that moved the lockfile and restore your files to the point before it. Feedback. You leave line comments in the Review Desk, and Hermes sends a line comment "back to the agent that wrote it" (README). For an agent running on your own machine, neither of the other tools closes that loop for you. Risk signals. The Review Desk shows changes with risk flags (README). That gives you a pointer to where to look first. Review to merged. Land "commits, opens a pull request or merges locally in one step, into the branch the task started from, and can be undone" (README). Undo data for a landed task is kept for 14 days (release notes). Your own checks can decide when a task is done. !Three small terminal windows, each with a robot silhouette, and a folded note flying back along an orange thread to the one terminal whose robot wrote the marked line Each line comment is routed to the agent session that wrote that line. The Review Desk is a single-person, local review. It has no approvals, no code owners, no required checks on a shared branch, and no CI history. Turn history exists only for sessions run in Hermes; a branch an agent pushed from somewhere else is just commits. In a task with extra folders, the replies strip tracks changes in the main project only (2.3.1 notes). And the turn view tells you which reply changed a line, not why the agent did it; you still read the transcript for that. Side by side | | GitHub PR view | lazygit | Hermes Review Desk | |---|---|---|---| | Smallest unit | Commit, then file | Hunk and line | Agent turn, then file | | Comments | Line, range, suggestions | None | Line comments | | Feedback to agent | @copilot, @claude (GitHub-hosted) | You type it | Sent to the agent that wrote the line | | Risk signals | Code owners, required checks, dependency review | None built in | Risk flags on changes | | Team review | Yes | No | No | | Undo | Revert PR | z via reflog | Restore a turn, undo a landing | | Where it runs | GitHub | Your terminal | Desktop app, your machine | Use them in order They don't compete as much as the table suggests. They sit at different points in the life of a change. 1. While the agent is still working, review by turn. That is when "restore to before turn 7 and tell the agent why" is cheap, and the comment reaches the right agent without a copy-paste. Hermes does this; so does reading git diff after every turn, if you have the patience. 2. Before you push, shape the history. If the result is one blob of a commit, lazygit's hunk staging and custom patches turn it into commits a teammate can follow. 3. Once others are involved, open the PR. Approvals, code owners, required checks and dependency review belong there, and they protect the branch from you as much as from the agent. If you work alone on a side project, step 3 may be a formality. On a team, it isn't optional, and no local tool should pretend otherwise. Hermes's Land step can open the pull request for you. Where do you review agent code today, and what slipped past you because of it? Tell me in the comments. --- If this was useful I build Hermes IDE: it is free to download, source-available under BSL 1.1, runs on macOS, Windows and Linux, and isn't affiliated with Nous Research, Anthropic, OpenAI or any agent vendor. If reviewing by turn sounds useful, try it on your next agent task and star it on GitHub or open an issue when something doesn't match what I wrote here. If the PR-and-CI step is where your small team still improvises, Ship It covers the road from localhost to production: CI/CD, hosting, auth, payments and monitoring, picked for a team without a platform department. 
Lazygit-ல் Git வேலைகள் எல்லாம் ஒரே திரையில் தெரிகின்றன. Stage, commit, rebase ஆகியவை விசைப்பலகையிலேயே முடிகின்றன. முதலில் எதை முயற்சி செய்வீர்கள்? jesseduffield/lazygit Instagram-லும் பின்தொடருங்கள்: instagram.com
⌨️ GitHub 好项目｜Lazygit 把 Git 常用操作放进终端界面：查看差异、按行暂存、整理提交，还支持交互式 rebase 和 worktree。 适合习惯键盘的开发者；需先安装 Git、理解提交与分支。MIT 许可，支持 Windows/macOS/Linux。 jesseduffield/lazygit 图：官方 README 演示截图 t.co
I run a dozen Claude Code sessions at once. This tmux console tells me which one needs me !15 seconds: status bar → picker → jump to the session waiting on you → switch account from the sidebar TL;DR — claude-tmux-sessions is a small set of tmux tools for running many Claude Code sessions in parallel. It answers three questions I kept asking myself: which session is waiting on me, what is everyone doing, and what do I do when one account runs out of quota? MIT, tmux + bash + python3, driven by Claude Code hooks. How I use Claude Code Some context first, or the design will look odd. I use two Claude accounts to push several projects forward at the same time: - One account per project. Each account has a 5-hour and a 7-day usage window. If one busy project shares an account with the others, it stalls them too. With an account per project, each has its own quota. - One session per role inside an account. Algorithms, backend, frontend, testing: one session each, so each context holds only its own part of the work and doesn't drift. - I only make decisions. I don't watch any one terminal. I go over when a session needs a yes/no, or when it has finished and I should look at the result. - Memory lives in files. Project rules, hand-off notes and a dev log are in the repository, so switching accounts or sessions loses nothing. That adds up to a lot of sessions open at once, more than one person can watch. tmux only manages windows; it has no idea what the Claude inside each window is doing. Hence this. Four pieces !The whole screen: Claude on the left, its sidebar on the right, the status bar at the bottom Status bar: who is waiting on you !Status bar: four counts on the left, the window list with a state per window, CPU/memory/swap/disk on the right Each session reports its state through Claude Code hooks, and the status bar counts them: - ⏸ waiting for your confirmation (a permission prompt is open and Claude is idle) — the only state that rings and sends a notification; - ✔ finished, and you haven't looked yet; - ▶ running, nothing to do; - ✓ finished, and you've seen it. The four counts never move: a zero turns grey but keeps its place, so you can click from muscle memory. Click ⏸ to jump to the session that has waited longest; click ✔ to get a list of just the finished-but-unread ones: !Clicking ✔: a picker with only the done-unread sessions floats up from the bottom That list is a tmux 3.7 floating pane, not display-popup, which is why clicking anywhere outside closes it — display-popup swallows clicks outside its box. Picker: what is everyone doing !Picker: grouped by project, numbered rows, live preview of the highlighted session prefix + g lists every session, grouped by tmux session (for me, one per project), with a live view of the one under the cursor. Every row is numbered; type the number to jump. It behaves like an inbox: visiting a session marks it read, and quiet ones fold away by default, so the list shows only what needs you. Sidebar: everything about this one session Every Claude gets a sidebar on its right that is about this session only: - Every turn. What you said and the start of the reply. Click a turn and the main pane scrolls to that turn's final answer. Turns before a /compact fold into one line. It reads the transcript file, not the screen. - Quota. Context, 5-hour and 7-day bars. Grey until something runs well ahead of an even pace. - Buttons. git (with the count of uncommitted files), files, refresh quota, switch account, close. The git and files buttons open lazygit and yazi floating over the right 60 % of the window, so the Claude on the left doesn't re-wrap; click outside and they're gone: !lazygit floating on the right, showing the diff of what Claude just changed Rule of thumb: global things go on the status bar, things about the current session go on the sidebar. The status bar is short on space, and this keeps both uncluttered. Switch accounts: keep going when one runs out Click ⇄ on the sidebar and the session exits, then comes back as claude --resume of the same session id under the other account. Same conversation, same context. There are guard rails: a session that is working is left alone; one with unsent text in its prompt is left alone (exiting would lose it); a window with agent-team teammates first gets a line typed to the lead asking it to wind the team down, and switches once they've exited. Trade-offs I made on purpose - Hooks, not screen scraping, for state. Sessions report their own state when it changes: accurate, no polling, no CPU. The screen is read only where there is no other way ("which turn is where", "is there unsent text"). - An inbox, not a dashboard. Things you've seen turn ✓ on their own and come back when that session does something new. Nobody maintains the list. - Everything is clickable. I work mostly by voice and trackpad, so every segment and button takes a click. Keyboard shortcuts are there too. - When in doubt, don't switch accounts. It skips and tells you why rather than risk losing anything. The rest of my setup The tmux console is one of four pieces. I also dictate almost every prompt with a push-to-talk voice tool (an LLM proofreads each transcript, and Claude adds the words it sees misheard to the vocabulary itself), and look back at usage and configuration in a local web dashboard. That's written up in docs/workbench.md. Try it git clone https://github.com/threedaycat/claude-tmux-sessions.git ~/projects/claude-tmux-sessions ~/projects/claude-tmux-sessions/install.sh --lang en Then add one line to your tmux config, source-file ~/projects/claude-tmux-sessions/tmux/claude-tmux.conf, and put the status-bar segments into your own status line; the README walks through it. Known limits, up front: I use it daily on macOS only (Linux is untested); you need a Nerd Font for the icons; and a few features read Claude Code's screen, so a Claude Code UI change may need a follow-up fix. Issues and PRs welcome.
Git without memorizing commands — LazyGit Git without memorizing commands — LazyGit LazyGit is a free, open-source terminal UI for git. Run one command inside any repo and you get panels for files, branches, commits and stash. Stage a hunk with space, drop to a single line when you only want part of it, and step through merge conflicts with the arrow keys — pick a side with space, take both with b, undo with z. Press c to commit with a message. Interactive rebase, cherry-pick, bisect, amend, worktrees, a commit graph and an undo command, all on keys. Free and open source (MIT), written in Go — 83,108 stars on GitHub. jesseduffield/lazygit #lazygit #git #terminal
🔥 [1 Repo Every Developer Should Know] lazygit: The Free Tool Taking Over GitHub! #shorts Discover jesseduffield/lazygit: simple terminal UI for git commands 💬 Comment "LAZYGIT" below for the direct link, or grab it from the links below: 👉 Interactive Star History & Live Analysis: githubrepo.cloud ⭐ Embed Live Verified Badges in your README: githubrepo.cloud 🔗 Direct GitHub Repository: jesseduffield/lazygit 📊 Repository Specs: ⭐ Stars: 82,912 🍴 Forks: 3,063 💻 Language: Go 📜 License: MIT #shorts #lazygit #cli #git #terminal #linux #devops #commandline #sysadmin
Repo link: jesseduffield/lazygit Runs 100% locally — nothing uploads. What paid tool should I replace next?
Stop Paying $69.00 for Tower Basic — This Free GitHub Repo Replaces It Tower Basic costs $69.00 a year per user. lazygit is free, open source, and runs entirely on your own machine. lazygit has 83,257 stars on GitHub and is licensed under MIT. Your data never leaves your own machine — nothing gets uploaded to anyone's cloud. ⭐ Repo: jesseduffield/lazygit ── SYSTEM REQUIREMENTS ── Windows: Windows 10 or 11; install with winget or Scoop, or download the release binary (official docs) · No stated minimum; lightweight single binary · Git must be installed (Git for Windows) macOS: macOS 10.12 or later for the release binary (official docs); or install with Homebrew or MacPorts · No stated minimum; lightweight single binary · Git (Xcode Command Line Tools or Homebrew git) ── WHAT YOU GET ── • LINE STAGING • INTERACTIVE REBASE • CHERRY PICK • COMMIT GRAPH • UNDO I post free open-source replacements for paid software every single day. If you're tired of subscriptions eating your budget, subscribe — there's a new one tomorrow. Searching for: free tower git alternative, lazygit, terminal git ui, free git client, interactive rebase made easy, lazygit tutorial #Shorts #lazygit #OpenSource #SelfHosted Pricing shown is Tower Basic plan, $69 per user billed annually (Tower lists it as $5.75 per user per month, billed annually) = $69 per user per year, checked 2026-10-17. Prices change — verify before you buy.
the new lazygit release drops the separate staging panel, you just stage lines straight from the focused diff. not sure how long my muscle memory takes to catch up github.com/jesseduffield/lazygit/releases/tag/v0.…
Git 变更太多，想在终端里直观看清楚？ lazygit 用交互式界面管理暂存、提交、分支和日志，减少频繁记命令的负担。适合学 Git 的开发者；重写历史前先检查差异。 jesseduffield/lazygit #Git #开发工具