omh-triage

OMH トリアージ — 合意に基づくバックログの整理

v0.1 の状況： このスキルは意図的に小さくしています。2 つの役割（Maintainer、Skeptic）で提供され、役割を追加する前に実地で検証しています。完全な設計仮説（Maintainer / Operator / Architect / Member-advocate / Skeptic）は、witt3rd/oh-my-hermes#9 にあります。次の具体的なマイルストーン（バージョン切り出し計画の圧力に対応する Operator の役割）は、witt3rd/oh-my-hermes#11 で追跡しています。現在の役割構成では表現できない実際の緊張関係が実施の中で明らかになった時点で、役割を追加していきます。ここでの基本方針は、まず実際に使って学び、その後に拡張することです。想定上の摩擦をもとに 5 つの役割すべてを最初から作る方法とは逆です。

使用するタイミング

• 課題バックログを定期的に整理するとき（標準の頻度：各バージョンの切り出し前、前回の整理以降に課題が 10 件以上蓄積したとき、または大規模なリファクタリングや移行が完了し、課題の前提が変わった可能性があるとき）
• 数日から数週間にわたる開発の進展（複数の移行やリファクタリング）によって、複数の未解決課題がすでに適用できなくなっている可能性があるとき
• ユーザーが「トリアージして」「バックログを整理して」「課題を一通り確認して」「古くなった課題はどれ？」と言ったとき

使用しないタイミング

• 設計が必要な、あいまいな課題が 1 件だけある場合（omh-deep-interview を使ってから omh-ralplan を使います）
• 一度も整理されておらず、課題が何百件もあるバックログの場合（まず手作業で初回の選別を行います。このスキルは、厳選されたバックログの妥当性を保つためのものであり、劣化したバックログを考古学的に調査するためのものではありません）
• 開発中に課題をクローズする場合（2 つのモードの規律を混在させないでください。開発中に記録し、整理時に判断します。ホストプロジェクトに存在する場合は docs/triage/PROCESS.md を参照してください）

前提条件

• 課題バックログを持つ対象リポジトリ（GitHub Issues。将来的には他のバックログにも対応可能）
• 任意：バージョン、クラスター、ステータスを対象とする GitHub Project（実行時に変更内容を書き戻します）
• 任意：前回の整理からの差分を把握するための、docs/triage/ 以下にある過去のトリアージ文書
• delegate_task ツールが利用可能であること

手順

フェーズ 0：事実確認の事前準備

役割を割り当てる前に、オーケストレーターが次の情報を収集します。

1. リポジトリの HEAD。 コミット参照を記録します。各判断はこれを基準にします。
2. 課題の一覧。 gh issue list --state open --limit <N> を実行します。件数、ラベルの分布、経過期間の分布を記録します。
3. 最近の移行／リファクタリング。 直近 N 週間のコミットログを確認します。割り当てる前に、どの領域が変更されたかをオーケストレーターが把握しておく必要があります。そうしないと、Maintainer が作業中にそのことを発見し、1 ラウンドを無駄にします。
4. 既存のプロジェクトボードの状態（存在する場合）。背景情報として、対象バージョン、クラスター、ステータスの各フィールドを確認します。
5. 過去のトリアージ文書（存在する場合）。最新の docs/triage/YYYY-MM-DD-*.md を、前回の整理からの差分を把握するための基準にします。

フェーズ 0 では、すべてのサブエージェントに渡す約 500 語のコンテキストパッケージを作成します。omh-ralplan のフェーズ 0 と同じ形式です。

フェーズ 1：役割ごとの確認（順次実施、可能な場合は並行）

v0.1 では 2 つの役割を提供します。 将来のバージョンでは、Operator、Architect、Member-advocate を追加します。

ステップ 1 — Maintainer による確認

delegate_task(
    goal="[omh-role:triage-maintainer] Vet each issue in the attached inventory against current code. Produce a per-issue verdict (stale/recast/live/partial-stale/out-of-scope) with code-anchored reasoning. Repo HEAD: <ref>. Inventory: <list>",
    context="# Project context\n\n<context-package>\n\n# Inventory\n\n<full issue bodies, not just titles>"
)

Maintainer による確認は課題ごとに行います。出力は構造化されており、課題ごとに 1 つのブロックを作成し、判断、根拠、理由、クローズコメントまたは改訂仕様を記載します。

ステップ 2 — Skeptic による確認（Maintainer の後に実施。入力として Maintainer の判断が必要）

delegate_task(
    goal="[omh-role:triage-skeptic] For each LIVE issue from the Maintainer pass, apply skeptical pressure: keep/drop/dedup/refile-smaller/wait-for-recurrence. Stale/out-of-scope issues do not need skeptical review.",
    context="# Project context\n\n<context-package>\n\n# Maintainer verdicts\n\n<Maintainer's structured output>\n\n# Full inventory (for cross-reference)\n\n<full issue bodies>"
)

Skeptic が確認するのは、Maintainer が有効または改訂対象と判断した課題のみです。古いものや対象外のものはすでにクローズに向けて進んでいるため、そこに二重の圧力をかけるのは、役割の注意力を無駄にします。

ステップ 3 — オーケストレーターによる集約

オーケストレーターは Maintainer と Skeptic の判定を組み合わせます。以下のマトリクスが正式な基準です — Maintainer × Skeptic のすべての組み合わせは、特定の処置に解決されます。ここに列挙されていない組み合わせのみが、真の競合としてユーザーへのエスカレーション対象になります。

Maintainer の判定 partial-stale（課題に複数のサブ主張が含まれ、一部は古く、一部は有効）は、マトリクス上では recast と同じものとして扱います — どちらも「本文に、おそらく大幅な修正が必要」を示します。再構成の仕様で、どのサブ主張が古く、どれが有効かを示せるよう、Maintainer の出力では引き続き両者を区別しますが、処置の解決方法は同じです。

Maintainer	Skeptic	解決後の処置
stale	(実行なし)	クローズ — Maintainer によるポインターコメント
out-of-scope	(実行なし)	クローズ — 再提出先を明記
recast / partial-stale	keep	本文を再構成し、オープンのままにする
recast / partial-stale	drop / wait-for-recurrence	クローズ — Skeptic によるポインターコメント（本文に修正が必要であり、根本の摩擦が重要な根拠にならない可能性もあるため、総合判定は「修正する価値がない」です）
recast / partial-stale	dedup	クローズ + 対象となる課題にコメント
recast / partial-stale	refile-smaller	クローズ + より小さな課題として再オープン
live	keep	有効
live	drop / wait-for-recurrence	クローズ — Skeptic によるポインターコメント
live	dedup	クローズ + 対象となる課題にコメント
live	refile-smaller	クローズ + より小さな課題として再オープン

このマトリクスは、このスキル（v0.1）における判定タイプを網羅しています。将来のバージョンで役割や新たな判定タイプが追加されると、マトリクスも拡張されます。競合として表面化するのは、新しい組み合わせに解決方法がない場合のみです。

エスカレーションのケース（v0.1 ではまれです）：Skeptic が needs lived signal（判定できない場合の役割の最終手段）、または役割カタログに列挙されていないその他の未解決値を返した場合、それは真のエスカレーションです。オーケストレーターは、これらを具体的な判断事項としてユーザーに提示します。オーケストレーターの役割は集約であり、マトリクスで解決できない場合にユーザーに代わって判断することではありません。

フェーズ 2：出力

オーケストレーターは次のものを作成します。

1. ホストリポジトリに（このスキルのリポジトリではなく）docs/triage/YYYY-MM-DD-<descriptor>.md のトリアージドキュメントを作成します。ホストプロジェクトのテンプレートを使用します。テンプレートがない場合は、references/triage-doc-template.md に記載された構成を使用します。
2. 判定実行計画 — クローズ（本文ファイルを /tmp/closeN.md にステージ）、再構成（提案する本文の差分付き）、より小さな課題として再提出するためのドラフトの一覧。
3. プロジェクトボードの更新（プロジェクトが設定されている場合） — 対象バージョンの変更、クラスターの更新、ステータスの変更。

オーケストレーターはデフォルトでステージングまで行い、実行はしません。ユーザーの承認ゲートはフェーズ 2 と実行の間にあります。references/orchestrator-review-template.md を参照してください。

フェーズ 3：実行（ユーザー承認後）

ユーザーの承認後：

1. ポインターコメントを投稿し、古い課題や却下された課題をクローズする
2. 再構成 PR（または本文の変更案を記載したコメント）を投稿する
3. プロジェクトボードのフィールドを更新する
4. 適切な作成者情報を付けて、トリアージドキュメントをコミットする

v0.1 の役割

役割	参照先	重視する観点
Triage Maintainer	references/role-triage-maintainer.md	コードに基づく事実確認：前提は有効か？
Triage Skeptic	references/role-triage-skeptic.md	整理：この課題は残す価値があるか？

v0.2 以降に予定されている役割（witt3rd/oh-my-hermes#9）：

• Operator — バージョンリリースの計画：正当化できる最小の vN+1
• Architect — 横断的な観点：どの課題が単一の根本原因による症状か
• Member-advocate — 実体験の観点：ユーザー／プリンシパル／存在が今何に困っているか

現在の 2 つの役割では表現できない緊張関係が、実際のラウンドで明らかになった場合に追加します。証拠が得られる前に作成することは避けてください。

出力品質基準

以下を満たした時点で、1 回の実行は完了です。

1. すべてのオープンな Issue に Maintainer の判定がある（未処理の Issue がない）
2. すべての対応継続／再構成対象の Issue に Skeptic の判定がある
3. すべての古い／クローズ対象の Issue に、投稿できるポインターコメントが用意されている
4. すべての再構成対象の Issue に、具体的な本文修正の仕様がある（「本文を書き直す」ではない）
5. 意見の相違は黙って解決せず、ユーザーにエスカレーションする
6. トリアージ文書に、今回対応しなかったこと（先送りした作業）が記載されている

落とし穴（v0.1。今後追加予定）

T1 — Phase 0 で真実となる情報を確認する前に Maintainer を割り当てない

Maintainer の役割は、現在のコードを基準にすることです。オーケストレーターが最近の移行／リファクタリングをあらかじめ把握していないと、Maintainer は作業中にそれを発見することになり、Phase 0 で提供されるべき情報を再調査するために注意を浪費します。

T2 — Skeptic がレビューするのは対応継続と再構成対象のみ

Maintainer が古い、または対象外と判定した Issue は、すでにクローズに向けて進んでいます。これらを Skeptic に送るとノイズが生じます（Skeptic は古い Issue に対して「ドロップ」と言うだけで、何も付け加えません）。

T3 — デフォルトでは実行せず、準備にとどめる

トリアージによるクローズは、Issue トラッカー上で取り消しにくい変更です。クローズは必ず本文ファイルを /tmp/closeN.md に用意してからステージングし、実際のクローズコマンドを実行する前にユーザーの承認を得てください。承認後にクローズを実行するスキルでは、シェル内で --comment "$(cat /tmp/closeN.md)" を使ってループ処理してください（execute_code の terminal() 経由で複数段落の本文を引用すると、エラーが表面化せずに失敗します。janus ラウンド 1 での教訓です）。

T4 — 組み合わせ表に記載されたケースはそこで解決し、列挙されていないケースのみエスカレーションする

Phase 1 のステップ 3 にある判定の組み合わせ表は権威ある基準です。live + drop は「クローズ — Skeptic のポインターコメント」と解決され、「ユーザーとの意見の相違」にはなりません。この表には、「Maintainer が対応継続と判断し、Skeptic がドロップと判断した」場合、Issue 自体は実在するが、そのために消費される枠に見合う価値はないという、慎重に検討された判断が反映されています。再発時には再登録するよう促す明確なポインターコメントを添えてクローズするのが正しい処置であり、ユーザーへの判断確認ではありません。

本当のエスカレーション対象は、Skeptic が needs lived signal（例外的な対応）を返した場合、Maintainer が needs investigation（例外的な対応）を返した場合、または将来、別の役割による判定が組み合わせ表に記載されていない組み合わせを生んだ場合です。v0.1 ではこれらはまれであり、「意見の相違がいくつかあります」ではなく、具体的な判断事項としてユーザーに提示します。

ディスパッチャーは、個々の Issue について、自身の基準に照らした判定の解釈が異なる場合、組み合わせ表を自由に上書きしてもかまいません。ただし、これはディスパッチャーの判断であり、表との矛盾ではありません。オーケストレーターのレビューでは、上書きしたことを明示してください（omh-ralplan-driver P25 — ここでも迎合より懐疑的な検討を優先します）。

T5 — 各ラウンドで永続的な文書を作成する

docs/triage/YYYY-MM-DD-*.md にあるトリアージ文書は、ラウンドの監査記録です。何を決定し、何を先送りし、今回のラウンドで何が分かったかを記載します。文書のないラウンドは、実施されなかったも同然です。

T6 — 不足している役割を急いで追加しない

このスキルは意図的に v0.1 です。OMH#9 の設計では 5 つの役割が定義されていますが、現時点で実装されているのは 2 つだけです。実際のラウンドで、それらの役割が必要となる具体的な緊張が見つかる前に Operator／Architect／Member-advocate を追加するのは、「想像上の摩擦」という失敗パターンです。証拠が得られるまで待ってください。

関連項目

• omh-triage-driver — ディスパッチャーの手引き（いつ呼び出すか、どう進めるか、良い出力とは何か）
• omh-ralplan-driver — 設計レイヤーにおける同様のスキル。規律のパターンは共通しています
• omh-deep-interview — トリアージで判断する前に明確化が必要な、曖昧な Issue 向け

参照

• witt3rd/oh-my-hermes#9 — 設計の追跡 Issue
• references/role-triage-maintainer.md
• references/role-triage-skeptic.md