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-leandrocfe-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. 掘り下げます（必要な場合）。 リクエストの詳細化が必要な場合は、/grilling と /domain-modeling のスキルを併用します。一度に 1 ラウンドの質問で内容を具体化し、ドメイン用語を明確にするとともに、決定事項が固まり次第 CONTEXT.md／ADR をその場で更新します。

5. 結果を適用します。

   • ready-for-agent — エージェント向け概要のコメントを投稿します（AGENT-BRIEF.md）。
   • ready-for-human — エージェント向け概要と同じ構成で、委任できない理由（判断が必要、外部アクセスが必要、設計上の決定が必要、手動テストが必要）を記載します。
   • needs-info — トリアージメモを投稿します（以下のテンプレート）。
   • wontfix — 理由に応じたコメントを付けてクローズします。
     • 既に実装済み — 変更はコードベースに既に存在します。実装箇所を示します。.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 に過去のトリアージメモがある場合は、それを読み、報告者が未回答の質問に回答しているか確認してから、最新の状況を提示して続行します。解決済みの質問を再度尋ねないでください。