MulmoTerminal の issue 作業コメント — OSS で同じ issue を 2 人が同時に直す無駄をなくす

課題：3 時間かけて直したら、2 日前に同じ PR が出ていた

日曜の午後、使っているライブラリの issue を見ていました。

#842 Windows でパスが二重になる

再現できたので、直し始めます。3 時間かけて PR を出しました。そこで気づきます。すでに同じ内容の PR が 2 日前に出ていました。

3 時間が無駄になったわけではありません。勉強にはなりました。でも、2 日前に知っていれば別のことをしていました。

逆の立場もあります。自分が直し始めた issue に、他の人が入ってくることもあります。そのときは「いま直しています」とコメントする手段がありますが、作業を始めるときは書き込むことを考えていません。数日後に思い出したときには、もう遅い。

工事の入口の札は、通行人のためではなく「次に掘ろうとする業者」のために掛かっています。掛ける側に得はありません。だから掛け忘れます。

既存のやり方とそのコスト

自分で「Working on this」とコメントする

できます。できますが、やりません。作業を始めるのは目の前の問題を解きたいからで、他人への告知が頭に浮かばないからです。思い出した頃にはもう手が進んでいて、「今さら書くのも」となります。

作業を始める前に issue 一覧を眺めて重複を探す

これで防げる場合もあります。ただし「2 日前の PR」は issue の下部のリンクに控えめに出るだけで、見逃します。issue のタイトルだけ読んで本文を読まないと、link された PR の存在に気づきません。

MulmoTerminal の解決：issue から着手すると、自動で 1 件コメントが付く

MulmoTerminal の Pull requests ビューで、issue の行末の ▶ を押すとエージェントが起動します。このとき、設定が有効なら issue に 1 件コメントが付きます。

Working on this in `842-windows-path`.
- started — 2026-08-04 14:20 UTC
posted by MulmoTerminal

次の人が issue を開いたとき、「3 時間前に誰かが着手している」ことが見えます。札が入口に掛かっている状態になります。

詳細

既定で無効

自分の GitHub アカウントで、しかも多くは他人が立てた issue にコメントを書く機能です。知らないうちに書いていた、では済みません。だから自分で有効にする形になっています。

パソコン単位の設定です。他人の issue に自動で書き込むかは方針の話なので、プロジェクトごとに変えるものではない、という整理です。

書くのは 1 件だけ。節目で編集する

着手、PR 作成、マージ — この 3 つの節目で、同じコメントを編集し続けます。新しいコメントは足しません。

Merged in #1240. Work done in `842-windows-path`.
- started — 2026-08-04 14:20 UTC
- PR #1240 — 2026-08-04 15:05 UTC
- merged in #1240 — 2026-08-04 16:40 UTC
posted by MulmoTerminal

3 件付けば、他人の issue のスレッドが自動投稿で埋まります。それは迷惑なので 1 件を編集し続けます。

テストの赤緑は書きません。1 つの PR で CI が 5 回赤くなることがあり、全部書けば issue が読めなくなります。節目を絞っているのが設計です。工事の札に「掘った土の量」は書きません。

時刻は UTC

3 週間前に書かれて以後動いていない宣言と、今朝動いた宣言は、読み手にとって別物です。「やっています」だけでは判断できないので、時刻を UTC で入れます。読み手が世界中にいるので UTC です。

工事の札の「工期」と同じ役目です。

フォルダ名だけ。上の階層は書かない

書かれるのはフォルダ名だけです。/Users/yourname/work/client-projects/... のような絶対パスは公開の issue に出しません。

副次効果もあります。issue ごとに作業フォルダを切る使い方では、2 つのターミナルや 2 人の人間が、同じ issue を二重に始めるのを止めます。自分の中での重複も防げます。

「posted by MulmoTerminal」と明記する

自動投稿であることを隠しません。他人の issue のスレッドに載るので、本当に作業しているのか、道具が勝手に書いたのかを読み手が判断できるようにしています。

二重に書かない仕組み

タブを何枚も開いていて、それぞれが定期的に問い合わせています。再読み込みもします。それでも 1 件しか書きません。

仕組みは、コメントに見えない印（HTML コメント）が入っていて、それを読み返すことです。節目もコメントの本文から読み出すので、2 回目以降は何も書きません。

状態を手元に持たず、コメント自身から読みます。複数のタブでも、再読み込み後でも、アプリの再起動後でも二重になりません。別のクローンで同じ issue を触れば 2 件目が付きますが、それは事実どおりです。

気づいた時刻であって、起きた時刻ではない

正直に書かれている制約です。書くのは、そのセルが実際に見た節目だけです。先月出した PR のブランチを再読み込みで開いても、過去の節目は遡って埋めません。知らないことは書かない、という態度です。

編集では通知が飛ばない

最初の 1 件は購読者に通知されます。以降の編集は通知を飛ばしません。「誰かが着手した」は知らせる価値があります。「その人が PR を出した」は PR 自身が通知します。他人の issue の購読者に、自動投稿の更新を何度も飛ばさない配慮です。

書けなかったときは、理由が出る

コメントを書くには、読む権限だけでは足りません。書き込む権限（gh auth status の Token scopes に repo または public_repo）が要ります。

書けなかったとき、セルに「issue を更新できていない」と小さく出て、直し方（gh を入れる、ログインする、権限を確認する）を名指しします。作業そのものには影響しません。コメントを飛ばすだけで、次の節目でまた試します。黙って失敗せず、かつ作業を止めない。

使ってみる

既存の MulmoTerminal インストールがあれば、設定を 1 行加えて再起動するだけです。初めての方は MulmoTerminal 完全ガイド の「使い方 3 ステップ」から。

動作確認の最小シナリオ

1. gh auth status で repo または public_repo scope があることを確認。無ければ gh auth refresh -s repo
2. ~/.mulmoterminal/config.json に { "issueWorkComments": true } を書くか、設定画面の GitHub and GitLab でチェック
3. アプリを再起動（この設定は起動時に 1 度だけ読まれる）
4. 自分のテスト用リポジトリで issue を立て、Pull requests ビューの ▶ ボタンで着手
5. issue に Working on this in … が 1 件付けば成功

他人の issue に自分の名前で書く機能です。まず自分のプロジェクトで試してから、OSS に使ってください。

やめるときは false にします。すでに書いたコメントは残るので、消したければ GitHub 上で自分で消します。

まとめ

• OSS では、着手を書かないと同じ issue を 2 人が直す。損をするのは次の人（そしていつか自分）
• MulmoTerminal は issue からの着手で自動的に「Working on this」コメントを 1 件書く
• 他人の issue に自分の名前で書くので、既定は無効。有効化は自己判断
• 1 件を編集し続ける、節目は 3 つに絞る、時刻を入れる、UTC で、フォルダ名のみ — すべて「他人のスレッドに載るから」の設計

関連: MulmoTerminal 公式ガイドの GitHub ページ / MulmoTerminal の git worktree 隔離 / MulmoTerminal の PR / Issue 横断ビュー / MulmoTerminal の PR 本文フッター