| name | pr-label |
| description | PR に「変更の種類」ラベルと、人間レビューの要否を示すラベルを付ける。「pr-label」「PRにラベルを付けて」と指示されたとき。 |
| argument-hint | [PR番号] |
PR Label
PRの差分・説明を読み、変更の種類ラベルを自動付与する。最終目的は 人間がレビューすべきPRとそれ以外を区別すること。そのために needs-human-review（人間レビュー要）を導出し、レビュー要否を確信をもって判定できないときは needs-manual-triage（自動判定の棄権）を付ける。
本スキルの役割と参照先
[!IMPORTANT]
（AI・必須） 変更の種類の定義（それぞれのラベルが何を指すか）と、どの種類が人間レビューを要するか（レビュー方針の選定）は docs/policy/pr-review-policy.md の「PRラベルと変更の種類」「ラベルとレビュイーの経験でレビュー方針を決める」節が正。本スキルはそれを自動付与する手順だけを定義し、基準本文は再掲しない（二重管理を避けるため）。記述がポリシーと食い違うときは常にポリシーを正とする。
実行開始時に上記ポリシーの該当節を読み、その定義で変更の種類を判定すること。
本スキルが所有するラベル
本スキルが付与するのは次の表のラベルだけ。これ以外の既存ラベル（人間や他ツールが付けたもの）には一切触れない。
| ラベル | 区分 | 説明（gh label create の --description に使う） |
|---|
| ポリシー「PRラベルと変更の種類」表の全ラベル | 変更の種類 | ポリシーの同表の「変更の種類」列をそのまま使う |
needs-human-review | レビュー要否 | 人間がレビューすべきPR |
needs-manual-triage | 自動判定の棄権 | レビュー要否を自動判定できなかった。人間が分類すること |
判定ロジック
ポリシーの定義に照らし、次の順で判定する。
1. 変更の種類ラベル（複数可）
確信をもって該当すると言えるものだけを付ける。ポリシーどおり、振る舞いの変更を含むなら他種別と併せて必ず feature を、.github配下・CI・静的解析の変更なら cicd を付ける。
docs / cicd / chore / policy … 変更ファイルのパスから機械的に判定できることが多い。policy の対象パスはポリシーの同表の備考が正feature / bug / refactor … いずれもアプリコードに触れ、意図（振る舞いの変更の有無）でしか区別できない。diff の内容と PR タイトル・本文を読んで判定する
2. needs-human-review（レビュー要否）
次のいずれかを満たすとき付与する。
feature / cicd / bug / policy のいずれかを付けた- レビュー要否の判定が不確実（後述）
seniority（ジュニアか否か）は承認後マージ↔事後レビューを分けるだけで「人間がレビューするか否か」の二択には影響しないため、本スキルは扱わない。
3. needs-manual-triage（不確実なときの棄権）
不確実性は 「feature が付くか（＝振る舞いが変わるか）」の判断に限定 する。bug/refactor/chore の見分けが付かないだけでは棄権しない。
- アプリコードに触れているが、PR説明が無い・曖昧などで振る舞いの変更があるか確信できないとき →
needs-manual-triage を付け、フェイルセーフで needs-human-review も付ける（ポリシー「迷ったときは、より厚いレビュー方針を選ぶ」に一致）
- このとき確信できる範囲の種類ラベルは付けてよい。どの種類も確信できなければ、種類ラベルは付けず
needs-manual-triage と needs-human-review だけを付ける
処理フロー
1. 対象PRの特定
- 引数に PR 番号があればそれを対象にする。
- 無ければ
gh pr view --json number で現ブランチに紐づく PR を対象にする。
- PR が見つからない場合は、判定を止めてその旨を表示して終了する（本スキルは既存 PR が前提）。
2. PR情報の取得
gh pr view <PR番号> --json number,title,body,files
gh pr diff <PR番号>
3. ラベルの存在確認・不足分の自動作成
ポリシー名を正とする。リポジトリに無いラベルだけを作成する（既存ラベルは上書きしない）。
gh label list --json name --jq '.[].name'
既存一覧に無いものだけ作成する（説明文は「本スキルが所有するラベル」表のとおり）。既存ラベルは作成しない（上書き防止）。
gh label create <名前> --description "<説明>" --color <色>
4. 判定
「判定ロジック」に従い、付与するラベルの集合を決める。
5. ラベル付与（追加のみ）
追加のみ。既存ラベルの削除はしない。 判定で決まったラベルだけを add する。
gh pr edit <PR番号> --add-label "<ラベル1>,<ラベル2>,..."
再実行で過去に付けたラベルが残ることはあるが、残るのはレビューを増やす（安全側）方向のみ。削除による事故を避けるため remove はしない。
6. 結果の出力
付与したラベルと判定理由は常に手元に表示する。PR へのコメントは needs-human-review の有無で分ける。
needs-human-review を付けなかった場合：コメントはしない。needs-human-review を付けた場合：gh pr comment で 1件だけ 投稿する。ラベルだけでは「なぜ人間レビューが要るのか」が PR 上に残らず、レビュワーが差分を読み直して判定を再現することになるため。
gh pr comment <PR番号> --body "$(cat <<'EOF'
## 自動ラベリング: 人間レビューが必要です
付与したラベル: `feature`, `needs-human-review`
`feature` を付与しました。ハンドラに新しい分岐が追加されており、アプリの振る舞いが変わるためです。
EOF
)"
- 判定根拠は 1〜2文。トリガーとなったラベル名と、差分から読み取った具体的な理由を書く。ラベル名の再掲だけで終えない（「
feature が付いたため」だけでは根拠にならない）。
needs-manual-triage も付けた場合は、同じコメントに次のセクションを続ける（コメントを2件に分けない）。
## 補足: レビュー要否を判定できませんでした
変更がアプリの振る舞いを変えるか（feature 該当か）を自動で判定できなかったため、`needs-manual-triage` を付けました。安全側に倒して `needs-human-review` も付与しています。
人間が変更の種類を確認し、適切なラベルへ付け替えてください。
- コメント本文に pr-review-policy へのリンクは入れない（コメントの可搬性を保つため）。
- 投稿後、コメントの URL を表示して完了とする。
使用方法
/pr-label # 現ブランチの PR にラベル付与
/pr-label 123 # PR #123 にラベル付与
