triage

トリアージ

リポジトリで設定されたトラッカー上で、課題を簡単な状態機械に沿って進めます。トラッカーの操作方法は docs/agents/issue-tracker.md から、ラベル文字列は docs/agents/triage-labels.md から読み取ります。どちらか一方でも存在しない場合は、その旨を伝え、続行する前に configure-repo を提案してください（その間も、読み取り専用でトリアージを行うことはできます）。

トラッカーの設定で外部からのプルリクエストが依頼の対象になっている場合、同じ状態機械に沿って処理します。**PR はコードが添付された課題です。**共同作業者が作業中の PR はトリアージの対象ではありません。明示的に指定された PR は、常に対象に含めます。

トラッカーに投稿するコメントはすべて、次の行から始めます。

> *This was generated by AI during triage.*

参考資料：agent-brief-template.md — ブリーフの形式と、その永続性に関するルールです。

状態機械

軸は 2 つあります。トリアージ対象の課題には、それぞれの軸から必ず 1 つずつラベルを付けます。

• カテゴリ： bug（動作の不具合）または enhancement（新機能）
• 状態： needs-triage → needs-info / shaping / ready-for-agent / ready-for-human / wontfix のいずれか

報告者が返信した場合、needs-info は needs-triage に戻ります。これらは正規のロール名です。ロール名と一致する場合を除き、ロール名そのものではなく、リポジトリで対応付けられたラベル文字列を付けてください。課題に矛盾する状態ラベルが付いている場合は、ユーザーに確認するまで変更しないでください。

対象範囲のルール

このスキルセット独自の計画を通じてユーザーが作成したものではない課題のみをトリアージします。作成時点でエージェント対応になっている課題は、本文内のマーカーで識別できます。plan-tasks が公開した Requirements covered: セクション、または publish-issues が公開した > *This issue was drafted by AI with で始まるマーカー行です。これらをトリアージすると、すでにある本来の仕様の上に、二重に弱い仕様を加えることになります。対象から除外し、その理由を伝えてください。

キューの表示

「何に対応する必要がありますか」と尋ねられたら、トラッカーを検索し、古い順に 3 つのバケットを提示します。各バケットには件数を付け、各項目を 1 行で要約します。（1）ラベルなし、（2）needs-triage、（3）最後のトリアージメモ以降に報告者からの更新がある needs-info です。PR が対象となる場合は、行に [issue] / [PR] のタグを付けます。ユーザーに選んでもらいます。

1 件の課題をトリアージする

1. 背景情報を収集します。 課題の本文、コメント、ラベル、作成者、日付をすべて読みます。PR の場合は差分も確認します。すでに回答済みの質問を繰り返さないよう、過去のトリアージメモも読みます。CONTEXT.md の用語集を使って、関連するコードを調べます。docs/architecture/ が存在し、課題がその対象とする中核部分に関係する場合は、ここで適合性を判断せず、コンフォーマンスの確認に REQUIRED SUB-SKILL: inspect-invariants を使用します。その後、次の 2 つを確認します。

   • 重複の確認： 求められている動作がすでに実装されていないか、コードベースを検索します。報告者の表現ではなく、ドメインの概念を使って検索します。すでに実装されている場合は、すでに実装済みとしてクローズする結果になります（手順 5）。根拠として、実装箇所と呼び出し方法を確認します。一致するものがなければ、検索した概念を記録します。
   • 過去の却下の確認： .out-of-scope/*.md を読み、このリクエストに類似する概念がないか確認します。キーワードではなく、アイデアが一致するかを見ます。一致するものがあれば、過去に何が却下され、その理由は何かをユーザーに伝え、判断を維持するか確認します。一致するものがなければ、その旨も記録します。

   完了条件： 両方の確認結果を記録していること。重複の確認では、既存の実装または検索した概念を明記し、過去の却下の確認では、一致する記録または一致するものがなかったことを明記します。

2. 主張を検証します。 何かを推奨する前に、その主張が正しいかテストします。バグの場合は、報告者の手順に沿って再現します。PR の場合は、差分をチェックアウトし、関連するテストやコマンドを実行して、説明どおりに動作するか確認します。次のいずれかを報告します。確認済み（コードパスを添える）、再現できず、または詳細不足。詳細不足は強い needs-info のシグナルです。完了条件： 報告者の言葉だけに頼らず、実際に確認した根拠があること。

3. 推奨します。 手順 1～2 の推論と根拠を添えて、カテゴリーと状態の推奨をユーザーに伝えます。曖昧さや説明不足があり、ユーザーにしか解決できない場合は、推奨を確定する前に、質問を 1 つずつ整理するため REQUIRED SUB-SKILL: clarify-decisions を使用します。ユーザーの指示を待ちます。

4. 結果を適用します。

   • shaping — 根本原因がまだ特定されていない確認済みのバグで、ブリーフを受け取るエージェントに調査を依頼することになる場合です。原因を未確定として明記したエージェントブリーフを投稿し、tier-1 のミニ仕様を書き、ビルドに必要な内容を整える /shape #N を記載します。klynt #242 のベースライン・トリアージ 4 件のうち 3 件では、ブリーフ自体に「修正の前に根本原因の調査が必要」と書かれていたにもかかわらず、推奨は ready-for-agent でした。/go と /board は、仕様が承認された場合にのみチケットを Ready として扱うため、#242 はビルドできるものがないまま Ready に留まっていました。
   • ready-for-agent — agent-brief-template.md を基に作成したエージェントブリーフを投稿します。ブリーフが契約となり、元の本文やスレッドは背景情報としてのみ扱います。
   • ready-for-human — 同じ構成のブリーフに、委任できない理由（判断が必要、外部アクセス、設計上の決定、手動テスト）を 1 行追加します。
   • needs-info — これまでに確認できたことを記したトリアージメモを投稿し、その後、報告者が回答できる具体的な質問を記載します（「詳細を教えてください」は不可）。
   • wontfix — クローズします。コメントの内容は理由によって異なります。
     • すでに実装済み： 手順 1 で確認した根拠を添えて、動作の実装箇所を示します。.out-of-scope/ には書かないでください。この KB は却下されたリクエストを記録するものであり、実装済みの機能を記録すると、後の重複確認を誤らせます。
     • バグの却下： 丁寧に説明してクローズします。
     • 機能強化の却下： 以下のルールに従い、概念に対応する .out-of-scope/ のファイルを新規作成または更新します。クローズ時のコメントからそのファイルにリンクし、クローズします。
   • needs-triage のままにする — ラベルを適用します。記録に値する進展が部分的にある場合に限り、コメントを投稿します。

   完了条件： 課題にカテゴリーラベルと状態ラベルがそれぞれ 1 つだけ付与され、必要なコメントが投稿されていること。

.out-of-scope/ ナレッジベース

コンセプトごとにファイルを1つ作成します。ファイル名はケバブケース（plugin-system.md）にし、イシューごとには作成しません。繰り返し寄せられる要望は、既存ファイルの「過去の要望」リストに追記します。各ファイルには、コンセプトを示す見出し、判断、長期にわたって有効な理由（プロジェクトの範囲、アーキテクチャ上の制約、意図的なトレードオフなど。「今は時間がない」は、却下ではなく先送りなので理由として使いません）、および要望が寄せられたすべてのイシューへのリンクを含むPrior requestsリストを記載します。将来の保守担当者が行動に移せるよう、平易な文章で書きます。ユーザーが過去の却下を覆す場合は、ファイルを削除または書き換え、新しいイシューを通常どおりトリアージします。

状態の直接変更

ユーザーがイシューと目標の状態（「#42 を ready-for-agent に移動」など）を指定した場合、それは判断であり、トリアージの依頼ではありません。そのため、調査／主張の検証／提案のプロセス（手順1～3）は省略できますが、ガードレールは省略できません。

1. 変更内容（ラベルの編集、コメントの有無、クローズするかどうか）を正確に伝え、トラッカーに変更を加える前にユーザーの承認を得ます。
2. ready-for-agent へ直接移動する場合は、agent-brief-template.md に沿ってブリーフを作成することを提案します。ブリーフのないエージェント対応イシューは、次のエージェントを困らせる原因になります。