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-utarn-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 に過去のトリアージメモがある場合は、それを読み、報告者が未回答の質問に回答しているか確認してから、最新の状況を提示して続行します。解決済みの質問を再度尋ねないでください。