課題：月曜の朝、どの PR が自分の番か分からない
先週出した Pull Request（以下 PR）が 4 本あります。4 つのプロジェクトに 1 本ずつ。
- 1 本目はテストが落ちている
- 2 本目はレビューで直してほしいと言われている
- 3 本目は通っていて、取り込むだけ
- 4 本目は相手の返事待ち
ところが、どれがどれなのか覚えていません。GitHub からのメールは金曜から 30 通来ていて、開いていません。4 つのプロジェクトを 1 つずつ gh pr list で確かめると、15 分使います。
本当に欲しい情報は、各 PR について次の 2 つだけです。
- テストが通っているか — CI の色
- レビューでどう言われているか — approved / changes requested / review required
この 2 つの組み合わせで、次に何をすべきかが決まります。
| テスト | レビュー | 誰の番か |
|---|---|---|
| 赤 | 未 | こちら — テストを直す |
| 緑 | 未 | 相手 — 待つ |
| 緑 | 直してほしい | こちら — 直す |
| 緑 | 通った | こちら — 取り込む |
4 行のうち 3 行がこちらの番です。朝に一度、この表を 4 本分見れば、その日やることが決まります。
既存のやり方とそのコスト
GitHub の Pull requests タブ
GitHub にログインして自分の PR 一覧を開けば、横断的に見られます。ただし、
- CI の色と review 状態が一行に揃わない（PR を開かないと分からない）
forkや contribute 先が混ざり、仕事で見るべきものを選ぶのに時間がかかる- モバイルで開くと縦に長い
gh pr list をプロジェクト数だけ繰り返す
cd ~/src/web && gh pr list
cd ~/src/api && gh pr list
cd ~/src/cli && gh pr list
cd ~/src/docs && gh pr list4 回打つと 15 分使います。CI の色も review の状態も、--json で引けますが、整形は自分で書くことになります。朝のたびにやる仕事ではありません。
自分でダッシュボードを書く
GitHub の API を叩けば一枚にまとめられます。ただし、
- トークンの管理が自分の責任になる
rate limitを超えないよう更新間隔を自分で決める- GitLab も使っているなら、別の API を書き足す
ダッシュボードが本業ではないので、やがて止まります。
MulmoTerminal の解決：登録したリポを 1 画面で、必要な 2 列だけ
MulmoTerminal のツールバーに Pull requests というボタンがあります。押すと、登録したリポジトリの未マージ PR と Issue が 1 画面に並びます。
PR の 1 行に出るのは、CI の色、PR 番号とタイトル、レビュー状態、作者、最終更新時刻。駅の電光掲示板と同じ情報密度です。放送（GitHub の全通知）より情報は少ないのに、判断はこちらで付きます。
詳細
見るリポは自分で登録する
自動では増えません。作業したフォルダや会話履歴からもです。設定画面の Pull request repos に owner/repo の形で追加するか、~/.mulmoterminal/config.json の prRepos に書きます。
{ "prRepos": ["acme/web", "acme/api"] }自動で集めると、一度触っただけのプロジェクトが延々と居座ります。見たいものは、触ったものより必ず少ない。登録制はこの判断です。
わざと自動更新しない
右上の ↻ Reload を押すまで、内容は変わりません。理由は 2 つあります。
- 裏で
ghコマンドが走るので、自動更新するとリポ数 × 間隔ぶんの API 呼び出しが黙って発生する - 見ているあいだに行が動くと、押そうとした行が別のものに変わる
掲示板が 1 秒ごとに書き換わったら読めない、というのと同じ設計です。
トークンを預けない
前提は gh auth login だけです。アプリはトークンを保存も参照もしません。gh のログイン権限でそのまま見ます。
さらに「どのリポを見るか」も必ずサーバ側の設定から取ります。ブラウザからのリクエストで指定はできません。画面を誰かに見られても、そこから別のリポを覗かせることはできません。
作業中のセルの横で開くと、そのリポが先頭に
Pull requests は 2 通りの開き方があります。全画面で開くか、作業中のセルの横に開くか。横に開くと、そのセルが指しているリポが専用の枠として先頭に出ます。開いている PR が 0 件でも「No open PRs」として先頭に出ます — 無いことも答えなので、出さないと読み込み中なのか本当に無いのかが分かりません。
行をクリックすると GitHub が別タブで開く
アプリの中では開きません。読むのも書くのも GitHub でやることなので、中途半端に真似しない、という割り切りです。
上限がある
1 リポあたり PR は 100 件、Issue は 20 件まで。超えると「これ以上あります」の注記と GitHub へのリンクが出ます。黙って切り捨てないので、全部出ていないことが分かります。
GitLab も同じ画面に並ぶ
"gitlab.com/group/project" のようにホスト付きで書けば、GitLab のプロジェクトも同じ画面に並びます。GitHub の gh と同じ役割を glab が果たすので、一覧も、Issue からの着手も、MR 作成も動きます。
1 つだけ違います。GitLab の行の CI ドットは、たいてい空です。MR 一覧にパイプラインの状態が入っておらず、読むには 1 件ずつ問い合わせが必要なためです。
自前ホスティング（gitlab.example.com）の場合は、同じファイルで一度だけ宣言します。アドレスからは GitLab なのか別のものなのか判別できないためです。
{
"gitlabHosts": ["gitlab.example.com"],
"prRepos": ["gitlab.example.com/group/project"]
}宣言したホストは gitlab.com と完全に同じに振る舞います。宣言する前は、その行が「未対応」ではなく「足すべき設定」を挙げて出ます。
使ってみる
既存の MulmoTerminal インストールがあれば、gh auth login 済みの環境でそのまま動きます。初めての方は MulmoTerminal 完全ガイド の「使い方 3 ステップ」から。
動作確認の最小シナリオ
- ツールバーの Settings → Pull request repos を開く
owner/repoを 1 つ追加（例:receptron/mulmoterminal）- ツールバーに現れる Pull requests ボタンを押す
- 開いている PR / Issue が、リポごとに件数付きで並べば成功
詳細な手順と設定キーは MulmoTerminal 公式ガイドの GitHub ページ にあります。
まとめ
- GitHub からの通知を 30 通受けても「どの PR が自分の番か」は分からない。必要なのは CI の色とレビュー状態の 2 列だけ
- MulmoTerminal の Pull requests ビューは、登録したリポの未マージ PR / Issue を 1 画面に並べ、その 2 列を 1 行で出す
- 自動更新しないのは、
ghの呼び出し回数と、見ているあいだに行が動く不快さの両方のため - トークンは預かない。
gh auth loginのまま。GitLab も同じ画面に並ぶ
関連: MulmoTerminal 公式ガイドの GitHub ページ / MulmoTerminal の git worktree 隔離 / Cursor の代替としての MulmoTerminal / tmux で Claude Code を並列に走らせる限界
