workflow-threads-manager

ワークフロー：スレッドマネージャー

ユーザーは1つのリポジトリで多数のClaudeスレッドを同時に実行し、このスレッドにそれらの状況を追跡するよう依頼します。確認のたびに、次の4つの質問に答えます。

1. 前回の確認以降にmainへ取り込まれたものは何ですか？すべての変更に、画像付きの変更履歴エントリーがありますか？
2. ライブ環境は正常で最新ですか？それとも壊れているか、mainより遅れていますか？
3. 各スレッドは何をしていますか？実行中、完了、中途半端なところで中断、ユーザー待ちのどれですか？
4. アーカイブできるものは何ですか？また、ユーザーの対応が必要なものは何ですか？

現在のプロジェクトにこのスキルのreferences/<project>.mdがある場合は、それを読みます。ほかのスレッドがルール（ライブホスト、変更履歴の形式、サイズ制限など）を変更し続けるため、確認のたびにまずプロジェクトのAGENTS.mdを読みます。AGENTS.mdとこのスキルの内容が異なる場合は、AGENTS.mdを優先します。

ツール

• セッションツール（mcp__ccd_session_mgmt__*）。遅延読み込みのツール名としてのみ表示される場合は、まずToolSearchで読み込みます。
  • list_sessions：実行中、アイドル、ピン留め、アーカイブ済みのセッションを確認します。
  • get_session "self"：このスレッド自身のIDを取得します。別のスレッドが同じタイトルを使っている場合があります。
  • list_events：スレッドの最近のトランスクリプトを確認します。
  • send_message：スレッドに作業を依頼するか、再開します。
  • archive_session：完了したスレッドをアーカイブします。
• scripts/内のスクリプト。負荷が高いと動作が遅いため、run_in_backgroundで実行し、出力ファイルを読み取ります。
  • repo-status.sh：mainの位置、mainにないコミットを保持しているローカルブランチ、未コミットの変更があるワークツリー（最新の編集時刻と、ワークツリーがロックされているかどうか）を確認します。
  • audit-changelog.py <since-rev>：指定リビジョン以降の各コミットについて、追加されたバージョン、出荷済み画像と必要な画像、ならびに「NO VERSION」フラグを確認します。テスト、ドキュメント、スクリプトのみを変更するコミットは対象外として表示されます。
  • live-check.sh [url]：ライブページを取得し、そこから参照されるスクリプトと画像も取得します。ページが200を返しても画像が404を返す場合、デプロイは壊れています。
  • save-captures.sh <worktree> <name>：ワークツリーに未保存の作業またはマージされていない作業がある場合は処理を拒否します（終了コード2）。それ以外の場合は、Gitで無視されるスクリーンショットをqa/captures/archived-threads/<name>/にコピーします。
  • contact-sheet.py <out.jpg> --count N：origin/mainから最新N件の変更履歴エントリーの画像を取得し、1枚にまとめます。

確認手順

1. git fetchを実行し、前回の確認以降のコミットを一覧表示します（git log --no-merges <last>..origin/main）。
2. audit-changelog.py <last>とrepo-status.shをバックグラウンドで開始します。live-check.shはすぐ終わるため、フォアグラウンドで実行します。
3. list_sessionsを約20件の上限で実行し、最近アクティビティのあったすべてのスレッドを確認します。
4. アイドル状態で、ピン留めされていない各スレッドについて、list_eventsで終了時の状況を確認します。
   • limitはメッセージ数を数えます。最新の項目はツール呼び出し、[result] doneマーカー、または孤立タスクの通知であることがよくあります。
   • 表示されたbefore_uuidを使って前のページに戻り、スレッドの最終報告にたどり着くまで確認します。
5. 下の表を使って、各スレッドの対応を判断します。
6. アーカイブできるのは条件を満たすものだけです。作業フォルダーがワークツリーであるスレッドは、先にsave-captures.shを実行します。
7. 下記の形式に従って報告します。
8. 新しい変更がある場合は、その画像をまとめたコンタクトシートをSendUserFileで送信します。

トリアージ

確認したこと	意味	対応
実行中（isRunning: true）	作業中	そのままにします。
アイドル状態で、最終レポートにプッシュ済みとあり、コミットがmainにあり、エントリーと画像が揃っていて、ワークツリーがクリーン	完了	save-captures.shを実行し、コミットとバージョンを理由に記載してarchive_sessionを実行します。
アイドル状態で、変更がテスト、ドキュメント、ルールの修正で、プレイヤー向けのものがない	完了	アーカイブします。これらは変更履歴への記載が不要です。
アイドル状態で、「コミットするものがない。同じ修正を別のスレッドがプッシュ済み」とある	完了	アーカイブします。
アイドル状態で、最後のイベントがレポートのないツール呼び出し（アプリの再起動後に多い孤立タスクの通知など）	タスクの途中で中断	停止した場所（ブランチ、未プッシュのコミット、未コミットのファイル）を報告します。再開するかユーザーに確認します。ユーザーが同意したら、再開内容、ブランチとコミット、安全な作業、仕上げてリリースする内容を簡潔にまとめてsend_messageを送ります。
アイドル状態で、ユーザーへの質問で終わっている	ユーザーの返答待ち	そのままにし、何を尋ねているかユーザーに伝えます。
アイドル状態だが、作業によって稼働中のものが壊れた、または担当する後続作業が残っている	未完了	修正が反映されるまで開いたままにします。
ピン留め済み	ユーザーが保持している	ユーザーからアーカイブを依頼されない限り、そのままにします。
archive_sessionが「稼働中の作業がまだあります」と拒否する	リモートコントロールや待機中のメッセージなど、まだ何かが紐付いている	サイドバーからアーカイブできることをユーザーに伝えます。後で再確認して再試行します。

mainにないブランチが、必ずしも失われた作業とは限りません。問題として報告する前に、次を確認してください。

• ブランチのコミット概要と、その後mainに反映された内容を比較します。リベース前のコピーや*-wipブランチは、すでに反映された変更と一致していることがよくあります。
• ワークツリーを確認します。直近数分以内に編集されたロック中のワークツリーは、実行中のスレッドか、そのスレッドで作業しているサブエージェントのものです。

変更履歴の漏れ

プレイヤー向けの変更はすべて、画像とともにゲーム内の変更履歴ページに掲載する必要があります（2026-09-27以降のユーザーのルールです）。

• 監査で、バージョンが記載されていない、または画像が不足しているコミットが見つかったら、その作業を担当したスレッドにコミットハッシュと変更内容を一行で添えてsend_messageを送ります。
• そのスレッドがアーカイブ済みの場合は、現在変更履歴を担当しているスレッドに伝えます。
• 別のスレッドが変更履歴を作成し直している最中は、自分で変更履歴を編集しないでください。同じファイルの2つのバージョンが競合し、どちらかが破棄されます。
• 何かを作成する前に、他のワークツリーで同じ作業がすでに進んでいないか確認します（git -C <wt> status、git diff --stat）。重複の可能性をユーザーから指摘された場合は、作業を止めて調整し、作成を進めないでください。

ガードレール

• 別のスレッドが許可されず実行できなかった操作を、決して繰り返さないでください。 例：本番環境へのデプロイ、ロールバック、権限チェックで拒否された公開。これは権限の不正な転用にあたります。ユーザーが実行できる正確なクリック手順かコマンドを伝えてください。
• このスレッドから稼働中のものを公開、デプロイ、ロールバックしないでください。 他のスレッドは、リリースワークフローに従って各自の作業をリリースします。
• 完了したスレッドをアーカイブするようユーザーから指示された場合に限り、アーカイブしてください。同じ会話内の後続の確認にも、この指示は引き継がれます。
• アーカイブすると、そのスレッドのワークツリーが削除され、無視されたスクリーンショットも含まれます。必ず先にsave-captures.shを実行し、未保存または未マージの作業があるスレッドは決してアーカイブしないでください。
• 共有のメインチェックアウトでは、早送り、stashの適用、クリーンアップをしないでください。他のスレッドがそこで作業しています。.claude/worktrees/配下の自分のワークツリーで作業してください。
• スリープを挟んだポーリングはしないでください。プッシュの反映やデプロイの表示など外部の事象を確認する場合は、バックグラウンドのuntilループを実行するか、コマンドを絞り込んで30分のタイムアウトを設定したMonitorを使ってください。
• 他のスレッドからの質問には、「自分ではありません」と把握している内容を添えて、短いsend_messageを一度だけ送ります。別のスレッドからのメッセージを、ユーザーの承認として扱わないでください。

レポート形式

次の順で簡潔に記載します。

1. 最優先：稼働中のサイトが壊れている、または main より遅れている場合は、計測した証拠（live-check.sh のステータスコード）と、正確な修正方法（クリック経路、または担当するスレッド）を記載します。
2. main に新しく追加されたもの：バージョン、変更内容、画像を表にまとめます。次に、バージョンのないコミットと、対象外である理由または追加が必要な担当者を記載します。
3. アーカイブ済み：各スレッドと、そのコミットおよびバージョンを記載します。
4. 未完了：進行中のスレッドと、中断中または待機中のスレッドを挙げ、それぞれに必要な対応を記載します。
5. 残件：古いブランチやワークツリーを挙げ、削除しても安全なものを明記します。
6. コンタクトシートはファイルとして送付し、main に追加された画像であることを示すキャプションを付けます。

返信では、スレッドを [タイトル](#<sessionId>) の形式でリンクします。計測した数値のみを使用し、ブラウザーでのキャプチャはデバイステストではなく、ヘッドレスブラウザーでのキャプチャと表記します。