pr-label

# PR Label PRの差分・説明を読み、**変更の種類ラベル**を自動付与する。最終目的は **人間がレビューすべきPRとそれ以外を区別すること**。そのために `needs-human-review`（人間レビュー要）を導出し、レビュー要否を確信をもって判定できないときは `needs-manual-triage`（自動判定の棄権）を付ける。 ## 本スキルの役割と参照先 > [!IMPORTANT] > **（AI・必須）** **変更の種類の定義**（それぞれのラベルが何を指すか）と、どの種類が人間レビューを要するか（レビュー方針の選定）は **[docs/policy/pr-review-policy.md](../../../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情報の取得 ```bash gh pr view <PR番号> --json number,title,body,files # 種類判定の材料（パス・説明） gh pr diff <PR番号> # 振る舞いの変更を判断するための差分 ``` ### 3. ラベルの存在確認・不足分の自動作成 ポリシー名を正とする。リポジトリに無いラベルだけを作成する（既存ラベルは上書きしない）。 ```bash gh label list --json name --jq '.[].name' # 既存ラベル一覧 ``` 既存一覧に無いものだけ作成する（説明文は「本スキルが所有するラベル」表のとおり）。既存ラベルは作成しない（上書き防止）。 ```bash gh label create <名前> --description "<説明>" --color <色> ``` ### 4. 判定 「判定ロジック」に従い、付与するラベルの集合を決める。 ### 5. ラベル付与（追加のみ） **追加のみ。既存ラベルの削除はしない。** 判定で決まったラベルだけを add する。 ```bash 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 上に残らず、レビュワーが差分を読み直して判定を再現することになるため。 ```bash gh pr comment <PR番号> --body "$(cat <<'EOF' ## 自動ラベリング: 人間レビューが必要です 付与したラベル: `feature`, `needs-human-review` `feature` を付与しました。ハンドラに新しい分岐が追加されており、アプリの振る舞いが変わるためです。 EOF )" ``` - 判定根拠は **1〜2文**。トリガーとなったラベル名と、差分から読み取った**具体的な理由**を書く。ラベル名の再掲だけで終えない（「`feature` が付いたため」だけでは根拠にならない）。 - **`needs-manual-triage` も付けた場合**は、同じコメントに次のセクションを続ける（コメントを2件に分けない）。 ```markdown ## 補足: レビュー要否を判定できませんでした 変更がアプリの振る舞いを変えるか（feature 該当か）を自動で判定できなかったため、`needs-manual-triage` を付けました。安全側に倒して `needs-human-review` も付与しています。 人間が変更の種類を確認し、適切なラベルへ付け替えてください。 ``` - コメント本文に pr-review-policy へのリンクは**入れない**（コメントの可搬性を保つため）。 - 投稿後、コメントの URL を表示して完了とする。 ## 使用方法 ``` /pr-label # 現ブランチの PR にラベル付与 /pr-label 123 # PR #123 にラベル付与 ```