pr-label

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 にラベル付与