antfu-issue-triage

Issue のトリアージ

現在のリポジトリ（gh repo view --json nameWithOwner）のオープンな Issue と PR を確認し、整理のための対応を提案します。判断はメンテナーが行い、エージェントは調査を担当します。

厳守ルール

• 承認されるまでは読み取り専用です。 ユーザーが対応一覧を承認する前に、コメント、ラベル付け、クローズ、編集を行ってはいけません。読み取り（gh issue view、gh api GET、gh search）は問題ありません。
• すべてのコメントに、エージェントによる自動投稿であることを明記します。 最後に独立した行として記載します（その前に空行を入れます）。🤖 *Automated by an agent.*
• コメントは簡潔で平易な表現にします。 簡潔な英語で書きます（利用可能であれば simple-english スキルを使用してください）。短い文を1～3文、能動態で記述し、専門用語や冗長な表現は避けます。各コメントは対象に合わせて新たに作成してください。定型文を使い回さないでください。対応の根拠となるリンク（PR、コミット、リリース、正規の Issue）を必ず含めてください。
• 承認された行のみを適用してください。ユーザーが行を編集または削除した場合は、その変更に正確に従ってください。
• 慎重に判断してください。不確かな場合は、クローズするのではなく、ラベル付けなどを提案して「オープンのまま」にしてください。ユーザーから指示がない限り、メンテナー間で議論中の項目、オープンな関連 PR がある項目、またはマイルストーンが設定されている項目をクローズしないでください。
• ハイフンのみを使用してください。em ダッシュや en ダッシュは使用しないでください。

ワークフロー

1. 対象範囲。 リポジトリと対象範囲を確認します（デフォルト：未対応の項目すべて。大規模なリポジトリの場合は、上限、ラベル、または経過期間によるフィルターを尋ねます）。一括で取得します：

   gh issue list --state open --limit 200 --json number,title,body,author,labels,createdAt,updatedAt,comments,reactionGroups,url,milestone
   gh pr list --state open --limit 200 --json number,title,body,author,labels,isDraft,reviewDecision,closingIssuesReferences,url,reactionGroups
   gh label list --limit 200 --json name,description
   

2. ラベルを確認します。 すべてのラベル名と説明を読みます。存在するラベルのみを適用します。新しいラベル（spam がない場合はそれも含む）は「ラベル」テーブルに記載し、承認後にのみ作成します。メンテナーが類似項目にどのようなラベルを付けているか確認します（gh issue list --state all --label <l>）。リポジトリのラベルを以下の「推奨ラベル」セクションと比較し、足りない有用なラベルを記録します。
3. 関連項目を整理します。 本文、コメント、タイムライン（gh api repos/{owner}/{repo}/issues/{n}/timeline --paginate）から相互参照を収集します：#123、URL、closes/fixes、関連する PR、別リポジトリへのリンク。関連項目はひとつのクラスターとして扱います。修正 PR がまだオープンの場合、issue をクローズしないでください。相互に関連付けられた項目同士を重複としてマークしないでください。
4. 各項目を確認します：
   • すでに修正済み／実装済み。 マージ済みの PR とコミット（gh pr list --state merged --search "<keywords>"、git log -i --grep）、変更履歴、ドキュメント、現在のコードを検索します。修正が含まれる最初のリリースを特定します（git tag --contains <sha> --sort=version:refname | head -1）。タイトルだけでなく、コードで確認します。部分的な修正は修正済みではありません。オープンのままにします。
   • 重複。 文言ではなく、症状または要望ごとにまとめます。特徴的な文言でオープンおよびクローズ済みの issue を検索します（gh issue list --state all --search "<text>"）。代表となる項目をひとつ選びます：関連する PR ＞ メンテナーの回答 ＞ 再現手順の明確さ ＞ リアクション数 ＞ 古さ。ほかの項目は代表項目に紐付けてクローズします。
   • スパム。 強い兆候が2つ以上必要です：宣伝／SEO／暗号資産のリンク、無関係な文章、同一投稿の繰り返し、リンク付きの空の本文、新規アカウントによる大量の活動。誤字、簡潔な文章、テンプレートの誤り、英語以外の文章はスパムではありません。
   • ラベル。 ラベルのない項目、または誤ったラベルが付いた項目に、既存のラベルを提案します。
   • 簡単に対応できる項目。 メンテナーが短時間で完了できる項目：承認済み、または CI が通過して対応可能な PR、変更内容が明確な小規模 PR、誤字やドキュメントの修正、再現手順が明確で小さな修正で解決できるバグ、小規模で明確に定義された要望です。それぞれがすぐ対応できる理由を示し、low hanging fruit ラベルを提案します。ブロック中、不明確、または大規模な項目は除外します。
   • 需要。 肯定的なリアクション（👍 ❤️ 🎉 🚀）、否定的なリアクション、コメントしたユーザー数、「+1」コメント、取り込まれた重複項目の数を数えます。リポジトリの規模を考慮して High / Medium / Low で評価し、実数も示します。古い項目でも最近動きがあれば、まだ要望があると判断します。
5. 以下のテーブル形式で計画を提示し、確認を求めて停止します。 このターンでは書き込みコマンドを実行しません。
6. 承認された行のみを、ひとつずつ実行します： コメント、ラベル付け、クローズの順に行います。最初の API エラーで停止し、その旨を報告します。リンク付きの完了／失敗テーブルで締めくくります。
   • 項目ごとにコマンドを1つ実行します（その項目へのコメント、ラベル付け、クローズを && で連結）。ひとつのスクリプトやループで多数の項目をまとめて処理しないでください。一括書き込みコマンドは権限分類器によってブロックされる場合があります。コマンドがブロックされた場合、回避策を講じないでください。項目ごとに小さなコマンドに分け、ユーザーに伝えてください。
   • 承認された新しいラベルは、まずそれぞれ専用のコマンドで作成します。
   • テーブル提示後にユーザーが追加した行（例：「#4 もクローズ」）には、同じスタイルで短い新しいコメントを作成し、最終レポートに記載します。

推奨ラベル

一般的なラベルです。まずリポジトリに既存のラベルがあるか確認し、意味が同じで名前が異なる場合は対応付けてください。既存のラベルの名前変更や削除は行わないでください。

グループ	ラベル	意味
種別	bug、enhancement、documentation、regression	アイテムの種類です。regression は、新しいリリース後にのみ発生する問題です。
トリアージ状態	pending triage、needs reproduction	アイテムがどの段階で止まっているかを示します。
解決	duplicate、invalid、wontfix、spam	クローズされた理由です。
優先度	p1-chore、p2-nice-to-have、p2-edge-case、p3-minor-bug、p3-significant、p4-important、p5-urgent	重要度を示します。説明：p5 はほとんどのユーザーに影響するため、すぐにリリースが必要です。p4 はドキュメントに記載された動作に影響します。p3 はエッジケース、または優先度の高い機能強化です。p2 はあると便利なもの、または回避策があるものです。p1 は動作を変更しません。
貢献	low hanging fruit	メンテナーがすぐに対応できるものです。
コンテキスト	has workaround、bug: upstream、<platform> only（例：windows only）	次の読者に役立つ追加情報です。
領域	feat: <area>（リポジトリの主要モジュールごとに 1 つ）	変更が及ぶコードの部分です。リポジトリのディレクトリ、ドキュメント、過去の Issue から領域を特定してください。
ボット	bot: maybe、bot: likely	スパムと断定するには至らない、ボットまたは LLM によるコンテンツの可能性を示します。

ルール：

• すべてのラベルに説明を記入してください。既存のラベルに説明がなく、意味が明確な場合は、説明を提案してください。
• このリポジトリのトリアージに役立つラベルのみを提案してください。確認したアイテムに必要なもの、または明らかな不足を補うもの（たとえば、再現手順のない Issue が多いのに「needs reproduction」を示す方法がない場合）が対象です。リスト全体を提案しないでください。
• 多数の推測的なラベルを作るより、実際の Issue のまとまりに裏付けられた feat: <area> ラベルを少数使ってください。
• ラベルの作成は書き込み操作です。名前、色（リポジトリの配色に合わせる）、説明、適用対象のアイテムを記載し、Labels テーブルに (new label) の行として追加してください。承認後にのみ、アイテムに適用する前に作成してください（gh label create <name> --description "..." --color <hex>）。

コメント

短く、親しみやすく、具体的にしてください。文体の例（そのまま転記しないでください）。それぞれ、次の通知を単独行に付けてください。

• 修正済み：

  This was fixed in #456, released in v1.2.0. Please upgrade to get it. If it still happens, comment with a repro and we will reopen.
  
  🤖 *Automated by an agent.*
  

• 重複：

  This is a duplicate of #123. Please follow that issue. Tell us if it is different and we will reopen.
  
  🤖 *Automated by an agent.*
  

• スパム：

  Detected as a spam. Sorry if this was a mistake. Let us know and a maintainer can bring it back.
  
  🤖 *Automated by an agent.*
  

種類ごとのルール：

• 修正済み： PR またはコミットとリリースへのリンクを記載し、必要な対応（アップグレード、オプションの有効化、API の使用など）を説明してください。完了としてクローズしてください。
• 重複： 正規の Issue を示し、内容が異なる場合は作成者に再オープンを促してください。not planned としてクローズしてください。
• スパム： spam ラベルを追加してください。理由は述べず、スパムとして検出されたことを伝えてください。誤判定の場合は謝罪し、再度対応できることを伝えてください。理由はコメントではなくテーブルに記載してください。not planned としてクローズしてください。

アクションテーブル

ユーザーが「1〜5を適用、3をスキップ」のように返信できるよう、行に番号を付けた3つのテーブルを用意します。テーブルにはコメント全文を表示します。

1. クローズ

#	項目	理由	リンク（修正／正規版）	コメント

Reason は fixed、duplicate、spam のいずれかです。スパムの行には spam ラベルも追加します。また、その理由はコメントではなく、このテーブルに記載します。

2. ラベル

#	項目	追加	理由

low hanging fruit の行もここに含めます。リポジトリにないラベルについては、項目を (new label) とし、ラベル名、説明、色、適用対象の項目を記載した行を追加します。承認された新しいラベルは先に作成し（gh label create）、その後に適用します。

3. 要対応（書き込み操作なし）

#	項目	要望	リアクション／コメント	メモ

最初に確認することが最も推奨される項目を、重要度順に上から配置します。需要の高さ、リグレッションやビルドを妨げるバグ、セキュリティ報告、セキュリティ上重要なPRや長期間待機しているPR、進行中で未回答の議論がある項目を含めます。Note にその理由を記載します。low hanging fruit も、すぐ対応できる理由とともに、これらの後に記載します。

依頼されない限り、古くなったことを理由にPRをクローズしないでください。代わりにラベルを付けるか、要注意として示してください。