Github Create Pr

---
name: github-create-pr
description: PR 作成を依頼されたときに、依頼範囲の変更を確認し、リポジトリのテンプレートに沿ったタイトルと本文で GitHub PR を作る。本文の下書きだけを求められた場合は公開しない。
context: fork
---

# PR を作成する

依頼された変更をレビューできる PR にする。
ユーザーが指定した対象、base、分割方針を優先し、作成した PR の URL を返すまで進める。
下書きだけの依頼では、タイトルと本文を返して完了する。

## 変更の範囲を確かめる

`git status`、現在のブランチ、remote、base との差分と commit 履歴から、PR に入る変更を確認する。
base はユーザーの指定とリポジトリの運用から判断し、ブランチ名を決め打ちしない。
base の repository とブランチ、head の repository とブランチ、push 先の remote を区別して確定する。
commit 済みの変更は `git diff <base>...HEAD` と `git log <base>..HEAD` で確認する。

未コミットの変更は、会話と差分から依頼に含まれると確認できるものだけを、内容に合った単位で commit する。
未追跡ファイルも列挙して内容を確認し、依頼範囲に含まれるかを判断する。
PR 作成の依頼を、手元の全変更を取り込む許可として扱わない。
範囲外の変更は保持し、秘密情報を含むファイルは commit しない。
commit メッセージはリポジトリの規約に従い、規約がなければ Conventional Commits を使う。
対象が明確なら、commit や PR 作成の承認を取り直さない。

範囲外の変更が既にブランチに含まれる場合も、そのまま公開せず、元の作業を保持して依頼範囲を分離する。
範囲や base を判断できず、誤った変更を公開するおそれがある場合は、その点だけを確認する。

## PR の規模を検証する

PR 作成前に、1 つの PR でレビューできる規模か、stack に分けるべきかを必ず評価する。
変更行数とファイル数に加え、変更が担う責務、独立してレビューできる単位、単位間の依存関係からレビュー負荷を判断する。
生成物や一括置換などの機械的な差分も区別し、行数やファイル数だけで分割を決めない。

1 つの PR では大きすぎると判断した場合は、その理由と、各 PR の目的、依存関係を示した分割案を提示する。
依存関係のある変更は stack、独立した変更は別々の PR とする案を示す。
分割方針が指定済みなら尊重し、指定された各 PR の規模を評価する。
分割方針が未確定なら、ユーザーの選択を待ってから分割と公開に進む。
既に方針が指定されている場合や判断を委任されている場合は、承認を取り直さない。
分割が不要なら、確認を求めず作成へ進む。
stack の構築と提出には、利用できる場合は `gh-stack` skill を使う。

## 本文を書く

冒頭で、何を変えるかと、なぜ変えるかを短く伝える。
レビューに必要な情報が伝わった時点で完成とする。
段落数や文字数を満たすために説明を増やさない。

ユーザーの説明、Issue、仕様を変更理由の情報源とし、diff と commit 履歴で事実を確認する。
理由を推測で補わない。
判断に必要な理由が不明なら、その点だけを質問する。

タイトルと本文はユーザーの言語に合わせ、語彙、文体、時制、確信度を保つ。
日本語で文体の指定がなければ常体を使う。
タイトルは変更の目的を簡潔に示し、リポジトリの規約に従う。
関連 Issue があればリンクする。

### 本文に残す情報

詳細は、ユーザーが求めた場合、または省くと変更の理解やレビュー判断を誤る場合に追加する。

- 選択理由は、実際に判断が必要だった点に絞る。
  代替案を後付けせず、採用しなかった理由が伝わる長さにする。
- 対象外の事項や変更しない点は、読者が今回の対応に含まれると誤解する場合だけ書く。
- 影響や戻しにくさは、互換性の変更、データ削除、移行手順など、具体的な判断材料がある場合に書く。
  根拠なく「影響は限定的」「安全に戻せる」と評価しない。

作業の時系列、ファイル別の diff 要約、自明な利点、将来の拡張可能性は書かない。
追従しただけの文書やテストの更新も列挙しない。
同じ内容を概要と詳細で繰り返さない。

### 説明の見せ方

短い文章で伝わるなら、そのまま書く。
関係や違いを文章で追う負担が大きい場合だけ、図、表、画像、短い変更前後の例を使う。

- 複雑な処理や依存関係は、判断に必要な部分だけを図示する。
- UI の変化は、実際の変更前後の画像で示す。
- 選択肢の比較が必要なら、案と判断理由を小さな表にする。

図や表を使うために説明を追加しない。
図から読み取れる内容を文章で繰り返さない。

検証結果は、未実施・失敗した必要な検証、通常の CI で扱えない手動確認、
変更固有のリスクに対する検証、テンプレートが要求する結果を書く。
通常の test、build、lint の成功は、明示要求がなければ書かない。

変更前後の結果が修正の理解に役立つ場合は、条件と観測結果を短く示す。
比較は必須にせず、取得していない結果を補わない。

### テンプレート

リポジトリ指定の PR テンプレートを使う。
指定がなければ `.github/`、リポジトリ直下、`docs/` を確認する。

テンプレートのセクションと構造は維持する。
非該当の欄は、別の指示がなければ空欄にし、`N/A` や埋め草を書かない。

テンプレートがなければ短い本文だけを基本とする。
見出しは、内容を分けることで読みやすくなる場合だけ付ける。
概要、変更一覧、検証、リスク、対象外の節を一律に作らない。

### 仕上げ

利用できる場合は `writing-tech-text` skill を使い、
日本語ではその `references/ja.md` も参照する。

各文について、削ると変更の理解やレビュー判断に必要な情報が失われるかを確認する。
失われない説明は削る。
削る際も、必要な制約や不確実性、ユーザーの確信度は保つ。

## 公開と完了

stack を選んだ場合は、stack の公開手順で提出し、以下の通常の公開手順は実行しない。
stack を公開できない場合は、単一 PR に切り替えず、未完了の操作と理由を報告する。

通常の PR は、確定した remote に依頼範囲のブランチを push する。
本文は実際の改行を含む一時ファイルに保存する。
各値を shell 変数に安全に格納し、展開を引用する。
`head_ref` は同じ repository ならブランチ名、ユーザー所有の fork なら `owner:branch` とする。
organization 所有の fork は `gh pr create --head` の owner 指定に対応していないため、push 後、下記の作成 URL を使う。

```bash
git push -u "$head_remote" "$head_branch"
gh pr create --repo "$base_repo" --base "$base_branch" --head "$head_ref" --title "$title" --body-file "$body_file"
```

作成前と、作成リクエストの応答が不明な場合は、既存の Open PR を確認する。
base の repository とブランチ、head の repository とブランチがすべて一致する場合だけ重複と判定する。
作成した PR の URL と、必要なら依頼から除外した変更を報告する。

`gh` が使えない場合、CLI で対象を扱えない場合、API 制限で作成できない場合は、push の成否を確認して次の形式の作成 URL を返す。
base repository を URL の公開先とし、head は同じ repository ならブランチ名、fork なら `owner:branch` とする。
ブランチ名、タイトル、本文は改行や特殊文字を含め percent-encode する。

```text
https://github.com/<base-owner>/<base-repo>/compare/<encoded-base>...<encoded-head>?quick_pull=1&title=<encoded-title>&body=<encoded-body>
```

これは作成済みの PR ではないと明記し、下書きのタイトルと本文、push を含む未完了の操作も伝える。

## ユーザーからの追加 context

$ARGUMENTS