triage-issue

GitHub Issue のトリアージ

概要

トリアージとは、type/ + priority/ ラベルを付け、記録すべき判断がある場合は重要なコメントを残し、その後 status/needs-triage を削除することです。gh label list でリポジトリのラベルスキーマを確認してください。以下で使用する type/* / priority/* / status/* の規則は一般的なデフォルトですが、実際のリポジトリに合わせてください。

対象範囲：1 回の実行につき 1 件の Issue です。バックログを順に処理する場合は、呼び出し元が gh issue list --label status/needs-triage で Issue を列挙し、結果ごとにこのスキルを呼び出します。

基本原則：コメントは儀礼ではなく、情報を伝えるものです。Issue の本文に伝えるべきことがすでに含まれている場合は省略してください。本文やラベルだけでは読者が把握できない情報がある場合にのみ追加してください。

使用するタイミング

• ユーザーが「triage #N」／「この Issue をトリアージして」と言った場合
• Issue に type/ または priority/ ラベルがない場合
• Issue に status/needs-triage が付いている場合

バックログ作業（triage backlog ／一度に複数の Issue を処理する場合）は、呼び出し元がオーケストレーションを行います。Issue を列挙し、Issue ごとにこのスキルを呼び出してください。

手順

1. Issue を読む：gh issue view <n>
2. 判断する前に本文を読む（タイトルだけでは範囲を把握できません）
3. ラベルを決める：type/ + priority/
4. コメントを付けるか決める：以下の「コメントの基準」を参照
5. 適用する：

   gh issue edit <n> \
     --add-label type/X --add-label priority/Y \
     --remove-label status/needs-triage
   gh issue comment <n> --body-file -  # stdin, multi-line safe
   

優先度の基準

レベル	条件
critical	認証バイパス · データ損失 · 本番環境の停止 · 現在進行中の悪用。すべての作業を中断してください。
high	現実的な攻撃経路を伴うセキュリティ問題 · 主要なフローの破損 · 他の作業を妨げる問題
medium	修正すべき問題 · UX の低下 · 明確な利点のあるリファクタリング · ユーザーに見える不具合はない
low	仕上げ · 整理 · あると便利な改善 · リスクの低いフォローアップ

判断の軸：影響を受ける対象、被害の可逆性、影響範囲です。2 つの段階のどちらか迷う場合は、低い方にしてください。

コメントの基準

次のいずれかに該当する場合は、必ずコメントしてください：

• priority/critical または priority/high — 後から判断の根拠を示せるよう、記録してください
• Issue が別の Issue と重複・関連している（see also #N / dup of #N / subset of #N / blocks #N）
• 範囲の見積もりが自明でない（XS / S / M / L、または時間・日数）
• ブロッカーがある（blocked by #N または requires upstream X）

次の場合はコメントを省略してください：

• タイトルと本文に優先度の根拠がすでに記載されており、相互参照・範囲・ブロッカーについて追加することがない
• コメントが本文の内容を言い換えるだけになる

本文を繰り返さないでください。投稿者がすでに重大な理由を説明している場合、トリアージコメントには メタ 情報、つまり関連性、範囲、日付、判断の妥当性を記載します。

トリアージ中にコードを読まないでください。実際のコードで主張を検証する必要がある、根本原因を確認する必要がある、または影響範囲を調査する必要があると分かった場合、それは調査です。investigate-issue スキルに切り替えて、その Issue を適切に調査してください。中途半端な調査は、簡単なトリアージよりもコメントの質を下げます。

コメントのテンプレート

リポジトリの PR テンプレートのスタイルに合わせ、ひと目で確認できるよう絵文字付きの見出しを使います。情報を追加しないセクションは省略してください（「N/A」の見出しは書かず、単に省略します）。

## 🏷️ Triage YYYY-MM-DD

`type/X` · `priority/Y` · effort: **S/M/L**

### 📊 At a Glance

<diagram (mermaid or ascii) + 1-line caption — only include when there's something visual worth showing>

Use a diagram when:

- Cluster fix order: `#29 → #30 → #25` (ascii arrows OK)
- Attack flow / race condition: mermaid `sequenceDiagram`
- Before/after refactor: mermaid `flowchart` or ascii box

Skip the section entirely (don't write empty header) when labels + Related list already convey the picture — most simple triages won't need it.

### 🔗 Related

- <only if relevant: dup of / blocks / blocked by / see also #N>

### 🚧 Notes

<only if priority justification missing from body, or scope is non-obvious>

言語：Issue の本文と同じ言語を使います。ラベルの値、コマンド名、セクション見出し（At a Glance、Related、Notes）はそのままにしてください。

規模：XS = 1 時間未満 · S = 半日 · M = 1～3 日 · L = 3 日超。行数ではなく、影響範囲から見積もってください。

セクションの基準：

• 🏷️ Triage の行と 📊 At a Glance — 必ず含めます（判断の要点となる概要です）
• 🔗 Related — 実際に関連 Issue へのリンクがある場合に含め、それ以外は見出しごと省略します
• 🚧 Notes — 本文に優先度の根拠がない場合、または範囲が自明でない場合にのみ含め、それ以外は見出しごと省略します

本文ですでに述べられていることを繰り返さないでください。トリアージコメントは 判断 に関するメタ情報であり、Issue の要約を再掲するものではありません。

クイックリファレンス

コマンド	目的
gh issue view <n> --json title,body,labels	issue を読み取ります
gh issue edit <n> --add-label X --remove-label Y	ラベルを適用します
gh issue comment <n> --body-file -	標準入力からコメントします
gh issue list --label status/needs-triage --json number,title,body,labels --limit 50	バックログを一覧表示します（呼び出し元が列挙し、issue ごとにこのスキルを実行します）

よくある間違い

• コメントで本文を繰り返す — ノイズが増えます。本文はすでにあるので、コメントはメタ情報だけにします。
• すべての issue にコメントする — 明確な中・低優先度の issue に何も書かないのは適切です。
• 「重要だが、ほかをすべて差し置くほどではない」ものに priority/critical を付ける — critical は真の緊急事態のために使います。迷ったら high を既定にします。
• --remove-label status/needs-triage を忘れる — issue がバックログフィルターにいつまでも残ります。
• 日付のずれ — コメントヘッダーには必ず今日の日付を使い、後から見たときにいつ判断したのか分かるようにします。