pr

name	pr
description	draft の Pull Request を作成するスキル。Conventional Commits でブランチを切ってコミットし、`gh pr create --draft` でPRを作成、本文は「背景／内容／論点」の3セクション構成にする。auto-ship.mdc により実装完了時はユーザー指示なしで自動トリガーする。明示的な「PRを作って」依頼時も使用する。既に PR が存在する場合はタイトルと description を更新する。

PR

draft の Pull Request を作成、または既存 PR を更新するスキル。Conventional Commits でのコミット、gh pr create --draft でのPR作成、本文の「背景／内容／論点」3セクション構成までを一貫して行う。

いつ使うか

• auto-ship.mdc により、実装・設定変更タスク完了時に自動トリガーされる
• 「PRを作って」「PR出して」等の明示的な依頼
• 既存PRに追加コミットが乗った状態で description の更新が必要なとき

設計思想

1. draft で出す: 自己レビュー（review-codes / review-docs スキル等）を挟む前提なので、最初は必ず draft。Ready for review は別ステップ
2. 本文は「背景／内容／論点」に絞る: diff から読み取れる事実（追加・削除・リネームしたシンボル、採用した API/ライブラリ名、変更ファイル一覧）は本文に書かない。レビュアが「何を判断すべきか」が伝わる構造にする
3. 「内容」はアプローチ・方針レベル: 「どんな設計判断のもとで何を実現したか」を書く。diff の言い換えは禁止
4. 既存PRがあれば更新一択: 新規作成と分岐する。コミットを積んだだけで description が古いまま残るのを防ぐ

手順

1. 変更内容の把握

git status と git diff（必要に応じて base branch との git diff <base>...HEAD）で、何が変わったかを把握する。複数コミットがある場合は git log で全体像を確認する。

2. 既存PRの確認

gh pr view --json number,title,body 2>/dev/null

既存PRがあれば 手順7（既存PR更新） へジャンプ。なければ手順3へ。

3. ブランチ確認

main / master ブランチ上にいる場合は、変更内容を反映した feature/<名前> 形式の新規ブランチを作成して切り替える。<名前> は Conventional Commits の scope と整合する名詞を使う。

4. ステージとコミット

未コミットの変更がある場合のみ実施する。

• ステージは ファイル名を明示して git add <path>。.env などの機密ファイルを誤って含めないよう、git add -A / git add . は使わない
• コミットメッセージは Conventional Commits（scope 必須） 形式

<type>(<scope>): <description>

• type: feat / fix / docs / style / refactor / test / chore / perf / ci / build
• scope: コードベースのセクションを表す名詞（auth / api / ui / config 等）
• description は「何をなぜ変えたか」を自己完結的に。「レビュー対応」「フィードバック反映」のようなトリガーをメッセージにしない（詳細は ~/.claude/rules/commit-message.md）

コミット本文に以下を含める:

Co-Authored-By: Claude Opus 4.5 <[e-mail]>

5. push

git push -u origin <branch-name>

upstream tracking を必ず設定する。

6. draft PR 作成

6a. PRテンプレートの探索

find . -maxdepth 3 \( -iname '*pull_request_template*' \) 2>/dev/null | head -20

テンプレートが見つかった場合は 構造を厳守 する。セクションを省略・並び替えしない。各セクションは下記「本文の書き方」原則のもとで埋める。

6b. 本文の書き方（背景／内容／論点）

本文は次の3要素だけで構成する。全体で簡素に保つ。レビュアが読むのは数十秒で、長い description は読まれない。

• 背景: 後続の内容・論点を理解するために最低限必要なコンテキスト（既存仕様の制約、過去の経緯、関連する障害・依頼、外部要件など）。それ以上は書かない。目安は1〜3文
• 内容: この PR で採った アプローチ・方針 を一段抽象的なレベルで述べる。diff の言い換えではない。「どのファイルを編集した」「どの関数を追加/削除/リネームした」「どのライブラリの API を呼んだ」は diff を見れば分かるので書かない。書くのは「どんな設計判断のもとで何を実現したか」のレベル。目安は2〜3文。箇条書きで変更を羅列しない
• 論点: レビュアに判断を仰ぎたい点、採用しなかった代替案とその理由、トレードオフ、残っている懸念、後続タスクに送る判断、命名や責務境界など意見が分かれる箇所。争点があるときだけ書き、無いなら本セクションごと省略する

コードを読めば自明なことは書かない（特に「内容」セクションで陥りやすい）。採用した API 名・関数名・追加したファイル名なども diff にあるので本文での再掲は不要。

テンプレートがある場合もこの原則を守る。テンプレートのセクションを埋めるためだけに変更内容を羅列してはいけない。書くことが無いセクションは「特になし」と書くか、テンプレートの指示に従う。

良い例（背景＋内容＋論点）

• 背景: Result 型のネストが深くなり既存コードで型推論が崩れていた
• 内容: Result の連結を andThen ベースから flatMap 統一方針に切り替え、ネストを潰した
• 論点: neverthrow 公式の慣用から外れるため将来のバージョンアップ時の移行コストが懸念。代替として andThen のままヘルパーを書く案もあったが、ヘルパーを覚える学習コストの方が高いと判断した

悪い例

• 内容が diff の言い換え: 「auth.ts の login 関数の return 文を ResultAsync に変更し、error.ts の MapError を削除し...」
• 背景しか書いていない: 「Result 型のネストを解消するため flatMap に統一した」← 何をしたか（アプローチ）と何を議論したいか（論点）が抜けている

6c. PR を作成

シェル引数に # を含む複数行テキストを直接埋め込むと権限プロンプトが余計に出るため、本文は一時ファイルに書き出して --body-file で渡す（詳細は ~/.claude/rules/shell-command-style.md）。

テンプレートが無い場合のデフォルト構成:

cat > /tmp/pr-body.md <<'EOF'
## 背景

<後続の内容・論点を理解するために最低限必要なコンテキスト>

## 内容

<採ったアプローチ・方針を一段抽象的なレベルで述べる。どのファイル・関数・APIを編集したかではなく、どんな設計判断のもとで何を実現したか>

## 論点

<レビュアに判断を仰ぎたい点、採用しなかった代替案とその理由、トレードオフ、残っている懸念、後続タスク送りにした判断など。論点が無いなら本セクションごと削除する>

## Test Plan

- [ ] <Testing steps>

---
Generated with Claude Code
EOF
gh pr create --draft --title "<conventional commit style title>" --body-file /tmp/pr-body.md

タイトルは Conventional Commits 形式（scope 含む）。作成後の PR URL をユーザーに返して終了。

Test Plan はコード変更で検証手順があるときだけ書く。ドキュメントのみの PR（docs:）では検証手順が無いので Test Plan セクションごと省略する。

7. 既存PR更新

既存PRがある場合は以下を実施する。

1. 未コミットの変更があれば手順4・5と同じ要領でステージ・コミット・push
2. ブランチ上の全コミットを再分析する（git log と base branch との git diff）。最新コミットだけでなく、PRに含まれるすべての変更を踏まえること
3. テンプレートを再確認（手順6a）
4. 現在の変更全体に基づいてタイトルと description を書き直す。「背景／内容／論点」原則は新規作成時と同じ
5. 本文を一時ファイル経由で渡して更新:

cat > /tmp/pr-body.md <<'EOF'
<更新後の本文>
EOF
gh pr edit --title "<更新後のタイトル>" --body-file /tmp/pr-body.md

完了後にPR URLをユーザーに返す。

注意点

• 並列実行可能なステップ（git status と git diff と gh pr view の確認など）は並列で投げる
• PR は 必ず draft で作成。Ready for review への移行は別ステップ
• PRテンプレートがある場合は その構造を厳守
• 本文は「背景／内容／論点」の3点に絞る。論点が無いなら論点セクションは省略する
• diff から読み取れる事実（追加・削除・リネームしたシンボル、採用した API/ライブラリ名、変更ファイル一覧）は本文に書かない