gh-news：GitHub notifications を terminal TUI で triage する
GitHub notifications は、小さいがじわじわ漏れる workflow friction になりやすい。browser の inbox は使えるが、code context とは切り離されている。terminal で branch を見て、test を走らせ、repo を切り替えたあと、また browser に戻ってどの PR mention を処理すべきか判断する。通知が増えると、面倒なのは link を開くことではなく、repo、reason、参加状態、今の task で先に分けることだ。
今日見たいのは chmouel/gh-news。Rust で書かれた gh CLI extension で、ratatui による terminal TUI として GitHub notifications を扱う。terminal の中で repo grouping、issue / PR / discussion / commit の preview、bulk mark-read、pin、snooze、regex filter、named views を使える。
GitHub repository API、repository page、README、Latest Release、LICENSE、Cargo.toml、default branch の Git history を 2026-07-31 時点で確認すると、chmouel/gh-news は 31 stars、6 forks。主要言語は Rust、license は Apache-2.0。repository は 2026-01-18 08:47:48 UTC に作成され、最近の public push は 2026-07-31 09:30:57 UTC。default branch main の現在の HEAD は e34ba1d、commit time は 2026-07-31 09:30:55 UTC。最新 GitHub Release は v0.18.0、published time は 2026-07-22 15:06:52 UTC。Cargo.toml の package name は gh-news、version は 0.18.0。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | chmouel/gh-news |
| 位置づけ | GitHub notifications 用 terminal TUI / gh CLI extension |
| Stars | 31 |
| Forks | 6 |
| 主要言語 | Rust |
| ライセンス | Apache-2.0 |
| GitHub 作成時刻 | 2026-01-18 08:47:48 UTC |
| 最新 push | 2026-07-31 09:30:57 UTC |
| 現在の default branch commit | e34ba1d、2026-07-31 09:30:55 UTC |
| 最新 GitHub Release | v0.18.0、2026-07-22 15:06:52 UTC |
| Cargo package | gh-news 0.18.0 |
| キーワード | GitHub notifications、gh extension、Rust、ratatui、terminal、TUI |
解いているのは通知の triage であって、表示だけではない
gh-news の README にある機能はかなり実務寄りだ。terminal-based UI、gh extension installation、vim-style navigation、multi-select、auto-refresh、preview、regex filtering、pin、repository grouping、mute、snooze、custom actions、named views、saved triage sessions、static display mode、configuration doctor。つまり GitHub notifications をただ表示するだけではなく、terminal の中に小さな triage desk を作る tool である。
複数 repo を見ている人には、この違いが効く。GitHub notifications の noise は一件ごとの message から来るというより、context switching から来る。ある repo では CI failure、別の repo では review request、どこかの discussion mention、issue comment が同じ inbox に混ざる。gh-news ならまず repo で group し、filter や named view で今見るべき work surface に寄せられる。
Preview も地味に重要だ。README では、issues、PRs、discussions、commits の detail を GraphQL-powered preview として見せると説明されている。通知が comment で発生した場合は、issue や PR の description ではなく、その comment を preview に出す。これは実際の使い方に合っている。多くの場合、知りたいのは「thread 全体」ではなく「誰が今何を言ったか」だからだ。
CLI workflow の流れを切らない
Install は軽い。
gh extension install chmouel/gh-news起動は次の通り。
gh newsgh CLI の下に入るので、authentication も既存の GitHub CLI workflow に沿う。README によると token lookup は GH_TOKEN、GITHUB_TOKEN、gh config file、最後に gh auth token の順番だ。すでに terminal で gh pr checkout、gh run watch、gh repo view を使っている人には、別 application を開くより自然に入る。
もう一つ良いのは、full-screen TUI だけに閉じていないことだ。README には --static-display があり、notifications を print して script や pipeline に渡せる。--check-config では filters、actions、token access、views を検査できる。日常 inbox としても使えるし、shell alias、tmux pane、status script、定期チェックにも組み込みやすい。
Grouping、snooze、named views が「既読にする」より大事
Notifications を処理するときにやりがちな失敗は、inbox を空にすること自体を目的にしてしまうことだ。実際の仕事では、delay、hide、keep、context switch のほうが多い。gh-news はこのあたりに機能を持っている。
Repository grouping は、関係ない project を折りたたみ、今見たい repo だけに集中するために使える。Pin は後で必ず戻る thread を残す用途に合う。Snooze は「今ではないが、永久に既読にしたくもない」通知に向いている。Mute threads と mute repositories は GitHub API 経由で扱うため、長期的な noise reduction に使える。
Named views と saved triage sessions は、より programmer tool らしい設計だ。参加中の通知だけ、特定 organization だけ、Actions workflow run だけ、現在の project の PR だけ、といった view を保存できる。毎回検索条件を思い出すより、terminal 内で workspace を切り替える感覚に近い。
Custom actions で自分の toolchain に接続できる
README には custom actions with command templates もある。これは notification triage を local toolchain に接続するのに向いている。特定種類の PR に対して script を走らせる、internal dashboard を開く、ある repo の通知を別 CLI に渡す、といったことができる。project 自体が全ての action を持つ必要はなく、現在の notification context を command に渡せれば、個人 workflow に入り込める。
もちろん、この種類の機能は慎重に扱うべきだ。local command を呼べる notification tool では、token scope、command template、shell environment を確認し、不可信な文字列が自動実行にならないようにしたい。gh-news には configuration doctor があるので、custom actions を有効にする前に走らせる価値がある。
注意したい境界
第一に、project はまだ小さい。31 stars、6 forks、2026 年 1 月作成で、最近も頻繁に更新されているが、多数の team で検証された infrastructure という段階ではない。個人 developer や小さな team の inbox tool として試すのが合っている。
第二に、GitHub API と token に依存する。README では status bar に rate limit remaining を出し、background refresh failure も報告すると説明されている。organization の通知量が大きい場合や token scope が厳しい場合は、まず小さく動かして API quota と permission が足りるか見たほうがいい。
第三に、TUI は priority 判断を代替しない。repo、filter、pin、snooze によって通知を扱いやすくできるが、すぐ review すべきか、merge してよいか、repo を mute してよいかは人間が決める。
第四に、機能が多い分、configuration も必要になる。たまに GitHub inbox を見るだけなら browser page で足りるかもしれない。gh-news が向いているのは、毎日 terminal で GitHub 作業をしていて、web inbox への往復が流れを切ると感じている人だ。
まとめ
chmouel/gh-news の価値は、「terminal でも通知が読める」という表面ではなく、GitHub inbox を filter、preview、bulk action、snooze、saved context を持つ TUI に変えるところにある。小さい tool だが、摩擦はかなり具体的だ。
GitHub notifications が少ない人や、普段 browser 中心で作業する人には必須ではない。しかし日常が gh、tmux、shell、複数 repo を中心に回っているなら、gh-news は試す価値がある。notification triage を terminal に残せるだけで、context switch は一つ減る。