triage

トリアージ

プロジェクトの課題トラッカー上の課題を、小さなトリアージ役割の状態機械に沿って移動します。

このリポジトリで外部からのプルリクエストを依頼の窓口として扱う場合（課題トラッカーの設定を参照）、トリアージの対象にはプルリクエストも含まれます。PR はコードが添付された課題として、同じ役割、同じ状態、同じ状態機械を使用します。以下では、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 行で表示してください。最後に 👇 を付け、メンテナーが番号または ID で選べるようにします。

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

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

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

3. 主張を検証する。 質問を重ねる前に、主張が妥当か確認します。バグの場合は、報告者の手順で再現します。PR の場合は、差分が主張どおりの動作をするか確認します。チェックアウトし、関連するテストやコマンドを実行します。結果を、確認済み（コードパスを含む）、失敗、または詳細不足（needs-info を強く示す）として報告します。検証で確認が取れると、エージェント向けの作業概要の質が大きく高まります。

4. 必要であれば質問する。 依頼の詳細を詰める必要がある場合は、「grilling」と「domain-modeling」のために Skill ツールを 2 回呼び出し、一度に 1 ラウンドずつ質問して内容を具体化します。ドメイン用語を明確にし、決定が固まったら GLOSSARY.md／ADR をその場で更新します。

5. 結果を適用する（チャットでの確認は該当する絵文字で始めます。トラッカーへのコメントは、必須の AI に関する免責事項以外は通常の文面にします）。

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

状態の簡易上書き

メンテナーが「move #42 to 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 に過去のトリアージメモがある場合は、それを読み、報告者が未回答の質問に答えているか確認してから、最新の状況を提示して続行します。解決済みの質問を繰り返さないでください。