omh-triage-driver

OMH トリアージドライバー — トリアージ実行の進行

v0.1 の状況： ワーカースキル（omh-triage）と同様、このディスパッチャーのプレイブックは意図的に小規模にしています。落とし穴は、実際のラウンドを重ねるなかで蓄積していきます。構造上のモデルとなるのは omh-ralplan-driver スキルです。こちらは、実際の複数回の実行で各失敗モードが明らかになってから、番号付きの落とし穴を25項目まで追加しました。このスキルは T1～T6 から始め、成長していきます。

オーケストレーターを務める場合

バックログに対して omh-triage を実行し、実際の Issue に対する判定（クローズ、再分類、バージョンの指定）を確定させるつもりであれば、あなたはオーケストレーターです。

スキルがどのような出力を生成するか確認する実験として omh-triage を実行する場合（実行する意図がない場合）、あなたはオーケストレーターではありません。実験では、ユーザーの承認ゲートを省略して、そのまま観察してください。ただし、出力ドキュメントでは実験的な実行であることを明記してください。

事前確認の徹底

omh-triage を実行する前に、次の確認を行ってください。

バックログの状態を監査する

1. Issue の数。 オープン中の Issue が10件未満なら、トリアージはおそらく不要です。手作業で判断してください。オープン中の Issue が100件を超える場合、バックログは劣化しています。実行前に、まず手作業で一次選別してください。
2. 前回の整理からの経過時間。 2週間未満で、かつ大規模なリファクタリングが入っていない場合は、ラウンドを実施する価値がないかもしれません。
3. プロジェクトボードの状態（ある場合）。「Won't ship」やステージング列にあるカードは、蓄積させたままにせず、トリアージラウンドで処理してください。
4. 最近の移行やリファクタリング。 これは重要な事前確認です。Issue の起票後、どの部分が変更されましたか？ 答えが「多数」なら、トリアージの効果は大きくなります。答えが「何もない」なら、効果は小さくなります。

実行のきっかけを監査する

今回の実行の実際の理由は何でしょうか？

• 「バージョン vN+1 をリリースするところなので、対象範囲を把握したい」→ トリアージでバージョンリリースの計画に役立つ情報を得られます。出力では、プロジェクトのバージョンフィールドを対象にしてください。
• 「大規模な移行をリリースしたばかりで、古くなった Issue がいくつかありそう」→ トリアージはクリーンアップ作業です。出力の大半はクローズになります。
• 「バックログが重く感じるので、削減したい」→ 懐疑派の圧力が中心となり、メンテナーはそれを支援します。それに合わせて目標を設定してください。
• 「定期的な整理で、特定の動機はない」→ 優先度は低いです。きっかけとなる理由ができるまで延期することを検討してください。

きっかけによって、各役割の出力にどの程度の重みを置くかが決まります。クリーンアップ作業ではメンテナーを重視し、削減作業では懐疑派を重視します。

ホストプロジェクトの運用体制を監査する

ホストプロジェクトには、次のものがありますか？

• クイック登録と整理の2モード運用を文書化した docs/triage/PROCESS.md。
• 対象バージョンとクラスターのフィールドを備えた GitHub Project。
• 比較対象となる過去のトリアージドキュメント。

ない場合は、まずこれらを作成するよう提案してください。omh-triage は日付入りのドキュメントを作成し、プロジェクトボードを更新します。それらを書き込む基盤がなければ、出力は失われます。

実行中のディスパッチャーの役割

フェーズ0（コンテキストの収集）中

コンテキストパッケージを作成するのはサブエージェントではなく、あなたです。このパッケージは両方のサブエージェントの作業内容を左右するため、誤りがあると両方の作業が無駄になります。

パッケージには次の内容を含めてください。

• Repo の HEAD ref（メンテナーが検証する際の基準点）
• 最近の移行やリファクタリングの一覧と簡単な説明（メンテナーが一から調べ直さなくて済むようにするため）
• Issue の数、ラベルの分布、経過期間の分布
• 過去のトリアージドキュメントの要約（あれば）。特に、どの判定が確定し、何が保留になったか
• 実行のきっかけの説明（クリーンアップ、削減、定期整理）

パッケージが約1000語を超える場合は、冗長です。目安は約500語です。

フェーズ 1（ロールによるレビュー）

まず Maintainer を実行し、そのライブ出力と再構成出力を受けてから Skeptic を実行します。最初から並列実行してはいけません。Skeptic がレビュー対象を把握するには、Maintainer の判定が必要です。

次の失敗パターンに注意してください（実際に発生したものは、それぞれ番号付きの落とし穴になります）。

• T1 — Maintainer がコミット参照なしで「古い」と主張する。 却下して根拠を求めてください。「最近の移行で対応済み」は有効な根拠ではありません。「v6（コミット c49abbf）で対応済み」は有効です。
• T2 — Skeptic が古いイシューをレビューする。 これはレビューの無駄です。スキル本文では対象外にするよう指示されていますが、ディスパッチャーが誤った一覧を Skeptic に渡すと発生します。
• T3 — サブエージェントがイシューごとのブロックではなく、まとまりのない説明文を出力する。 スキルの出力形式が構造化されているのには理由があります。要約にはイシューごとの解析が必要です。却下して構造化された出力を求めてください。

フェーズ 2（要約）

オーケストレーターであるあなたが、スキルの判定統合マトリックスに従って解決策の表を作成します。意見の食い違いは自動解決せず、ユーザーに委ねてください。どのイシューが対立しているのか、具体的に示してください。「いくつか意見の食い違いがあります」だけでは不十分です。

そのラウンドで意見の対立がなかった場合も、記録する価値があります。今回のラウンドではロール間の圧力がうまく調和していた（良いこと）のか、ロールが十分に厳しく検討しなかった（悪いこと）のかを示しています。対立がない状態が数ラウンド続いたら、3つ目のロールを追加するタイミングです。

フェーズ 3（実行）

ユーザーの承認が必要です。クローズ、再構成、ボードの更新を実行します。実際のクローズコマンドには /tmp/closeN.md とシェルループの慣用パターンを使ってください（execute_code の terminal() は使わないでください。複数段落にわたる引用本文がそこで黙って失敗することがあります。janus の第 1 ラウンドで学んだ教訓です）。

実行後、ラウンドのドキュメントを作成します。ドキュメントには、実施したこと、先送りしたこと、そしてそのラウンドから得られた教訓を記載します。後続のラウンドで確認された場合は、PROCESS.md またはこのスキルに反映するとよい教訓です。

落とし穴（v0.1）

T1 — 事実確認の事前準備を省略する

ディスパッチャーが最も大きな効果を発揮するのはフェーズ 0 です。事実確認が不正確な状態で実行すると、複数ロールの合意に基づいているために権威があるように見える、古い判定が生まれます。規律として、誰かに依頼する前に 10 分かけて最近の移行を把握してください。

T2 — 実行前にトリアージのドキュメントを作成する

判定をドキュメントに書き込んでから、結果を「検証」するために omh-triage を実行してはいけません。ロールの役割はディスパッチャーが見落とした点を明らかにすることです。ディスパッチャーがすでに結論を出しているなら、ロールは見せかけにすぎません。ドキュメントは実行結果に基づいて作成し、実行結果を誘導するために作成してはいけません。

T3 — 実行のスコープを広げてしまう

整理ラウンドのスコープは明確です。実行時点で未解決のイシューが対象です。ロールが「X も再設計すべきです」と指摘した場合、それは別の ralplan であり、トリアージの対象ではありません。ラウンドのドキュメントの「先送り」セクションに記載し、実行ループの中で扱おうとしないでください。

T4 — クローズ対象の山を軽く扱う

クローズは取り消しにくいものです。誤ってクローズしたイシューは、誤って残したイシューよりも復旧がはるかに困難です。ロールの判定が明確に感じられる場合でも、投稿する前に参照コメントをすべて読んでください。Maintainer の「古い」という判定は、あなたが承認すべき判定であり、鵜呑みにすべきものではありません。

T5 — 意見の対立を決定ではなく質問として提示する

ロール間で意見が異なる場合、あなたの要約では、ユーザー向けに具体的な判断を求める質問を作成してください。「これら N 件のイシューについて意見の食い違いがあります」のような一般論ではいけません。各対立について、次のように示してください。「Maintainer は理由 A から X と判断しています。Skeptic は理由 B から Y と判断しています。私の推奨は Z です。」そのうえで質問してください。（omh-ralplan-driver の P25 — 追従よりも懐疑を参照。）

T6 — 実行頻度が高すぎる

整理は毎日行うものではありません。毎週 omh-triage を実行しているなら、根本的な問題はチームが対応できる以上のイシューが登録されていることです。解決策は上流にあります（登録時の規律を高める、バックログを小さくする、新規イシューを減らすなど）。トリアージを増やすことではありません。

テンプレート

• plugins/omh/skills/omh-triage/references/triage-doc-template.md — ラウンド文書の構成
• plugins/omh/skills/omh-triage/references/orchestrator-review-template.md — あなたによる実行前レビュー

関連項目

• omh-triage — ワーカースキル
• omh-ralplan-driver — これが踏襲した構造モデル
• ホストプロジェクトの docs/triage/PROCESS.md が存在する場合 — トリアージがその中で実行する 2 モードのクイックファイル／グルーミングの手順を定義します