triage

トリアージ

プロジェクトのイシュートラッカー上で、トリアージ担当の小さなステートマシンを使ってイシューを進めます。

このリポジトリで外部プルリクエストを依頼の窓口として扱う場合（イシュートラッカーの設定を参照）、トリアージの対象には外部プルリクエストも含まれます。PR はコードが添付されたイシューとして、以下で「PR の場合」と記された差分を除き、同じ担当、同じ状態、同じステートマシンを使います。単独の #42 は、トラッカーの設定に従ってイシューまたは PR として解決します。

トリアージ中にイシュートラッカーへ投稿するすべてのコメントやイシューは、必ず次の免責事項から始めてください。

> *This was generated by AI during triage.*

参考ドキュメント

• AGENT-BRIEF.md：長く使えるエージェントブリーフの書き方
• OUT-OF-SCOPE.md：.out-of-scope/ ナレッジベースの仕組み

担当

カテゴリ担当は2種類です。

• bug：何かが壊れています
• enhancement：新機能または改善です

状態担当は5種類です。

• needs-triage：メンテナーによる評価が必要です
• needs-info：報告者からの追加情報を待っています
• ready-for-agent：仕様が完全に定まり、AFK エージェントが対応できます
• ready-for-human：人間による実装が必要です
• wontfix：対応しません

PR の場合、同じ状態は添付されたコードを基準に読み替えます。ready-for-agent はブリーフが添付されており、エージェントが差分の次のステップに進むべき状態です。ready-for-human は、人間がマージできる状態です。

トリアージ済みのイシューには、カテゴリ担当をちょうど1つ、状態担当もちょうど1つ付けてください。状態担当が競合している場合は、その旨を伝え、ほかの作業を始める前にメンテナーに確認してください。

これらは正式な担当名です。イシュートラッカーで実際に使用するラベル文字列は異なる場合があります。対応関係は提示されているはずです。提示されていない場合は、ユーザーに /setup-matt-pocock-skills を実行するよう伝えてください。

状態遷移：ラベルのないイシューは通常、まず needs-triage に移行します。そこから needs-info、ready-for-agent、ready-for-human、wontfix のいずれかに移行します。needs-info は、報告者から返信があった時点で needs-triage に戻ります。メンテナーはいつでも状態を上書きできます。不自然に見える状態遷移があれば、その旨を伝え、実行前に確認してください。

呼び出し

メンテナーは /triage を呼び出し、自然な言葉で希望する作業を説明します。依頼を解釈して対応してください。例：

• 「対応が必要なものを表示して」
• 「#42 を見てみよう」（イシューまたは PR）
• 「#42 を ready-for-agent に移して」
• 「エージェントが着手できるものはどれ？」

対応が必要な項目の表示

イシュートラッカーを検索し、3つのグループに分けて古い順に表示します。

1. ラベルなし：トリアージが一度も行われていません。
2. needs-triage：評価中です。
3. トリアージのメモ以降に報告者の活動があった needs-info：再評価が必要です。

PR が対象に含まれる場合は、外部 PR も各グループに含め、各行に [PR] または [issue] を付けてください。検出対象となるのは外部 PR のみです（誰を外部とみなすかはトラッカーの設定で定義されています）。そのため、コラボレーターによる進行中の PR はトリアージ対象ではありません。このフィルターは検出時のみ適用されます。明示的に指定された PR は、投稿者にかかわらず必ずトリアージしてください。

件数と、項目ごとの1行の概要を表示します。次に行う項目はメンテナーに選んでもらってください。

特定の issue または PR をトリアージする

1. 背景情報を集めます。 issue または PR の全文（本文、コメント、ラベル、作成者、日付。PR の場合は差分も）を読みます。以前のトリアージメモを確認し、解決済みの質問を再度尋ねないようにします。プロジェクトのドメイン用語集を使ってコードベースを調べ、該当領域の ADR に従います。コードベースに対して次の 2 つを確認します。（a）重複：リクエストの表現だけでなく、ドメイン上の概念に基づいて、求められている動作がすでに実装されていないか検索し、調べた場所を報告します。見つかった場合は、すでに実装済みの wontfix とします（手順 5）。（b）過去の却下：.out-of-scope/*.md を読み、このリクエストに似たものがあれば提示します。

2. 推奨を伝えます。 カテゴリーと推奨する状態を、理由とともにメンテナーに伝えます。さらに、リクエストに関係するコードベースの概要（すでに実装されているかどうかを含む）を簡潔に説明します。指示を待ちます。

3. 主張を検証します。 詳細を問い詰める前に、主張が妥当かを確認します。バグの場合は、報告者の手順に沿って再現します。PR の場合は、差分が主張どおりに動作するかを確認します。チェックアウトして、関連するテストやコマンドを実行します。確認できた内容（コードパスを含む）、失敗したか、詳細が不足しているか（needs-info とすべき強い根拠）を報告します。検証が取れていれば、エージェント向けの依頼内容をより明確にできます。

4. 詳細を問い詰めます（必要な場合）。 リクエストを具体化する必要がある場合は、Skill ツールを「grilling」と「domain-modeling」に対して 2 回呼び出し、一度に 1 回分の質問を行って内容を練り上げます。ドメイン用語を明確にし、決定事項がまとまり次第、CONTEXT.md／ADR をその場で更新します。

5. 結論を適用します。

   • ready-for-agent：エージェント向け依頼コメントを投稿します（AGENT-BRIEF.md）。
   • ready-for-human：エージェント向け依頼と同じ構成にしますが、委任できない理由（判断、外部アクセス、設計上の決定、手動テスト）を記載します。
   • needs-info：トリアージメモを投稿します（以下のテンプレート）。
   • wontfix の場合は、理由に応じたコメントを付けて issue をクローズします。
     • すでに実装済み：変更はコードベースにすでに存在します。該当箇所を示します。.out-of-scope/ には書き込まないでください。このナレッジベースは、実装済みの機能ではなく、却下したリクエストを記録するためのものです。
     • 却下（バグ）：丁寧に説明してからクローズします。
     • 却下（機能拡張）：.out-of-scope/ に記録し、コメントからリンクしてからクローズします（OUT-OF-SCOPE.md）。
   • needs-triage：役割を適用します。進捗が一部ある場合は、任意でコメントを投稿します。

クイック状態変更

メンテナーから「#42 を ready-for-agent に移動して」と指示された場合は、その指示を信頼して、役割を直接適用します。実行する内容（役割の変更、コメント、クローズ）を確認してから実行します。詳細を問い詰める手順は省略します。質問を行わずに ready-for-agent に移動する場合は、エージェント向け依頼を作成するかどうかを尋ねます。

Needs-info テンプレート

## Triage Notes

**What we've established so far:**

- point 1
- point 2

**What we still need from you (@reporter):**

- question 1
- question 2

質問の過程で解決した内容はすべて「これまでに確認できたこと」に記録し、作業内容が失われないようにします。質問は具体的で実行可能なものにし、「詳細を教えてください」のような質問は避けます。

前回のセッションを再開する

issue または PR に以前のトリアージメモがある場合は、それを読み、報告者が未解決の質問に回答しているか確認してから、状況を更新して提示します。解決済みの質問を再度尋ねないでください。