pr-creator

pr-creator

AI が差分を要約するのではなく、開発者が Slack に投稿するような PR の説明を書きます。レビュアーはあなたの背景情報を何も知らないため、本文では差分だけでは伝わらない「なぜ」「間違っていた場合の影響」「どの点について意見を求めているか」に答えます。変更内容は差分が示します。

• 対象： GitHub PR のタイトル、本文、ドラフト状態、レビュアーの作成または更新、UI 変更時のビジュアルの添付に加え、大きな差分を読みやすくするコミットの再構成とレビューの進め方です。
• 対象外： 差分内のコードの変更やバグレビュー（tidy を使用）、PR 作成後の CI やレビューコメントの監視（pr-babysitter を使用）、npm リリースの作成（autoship を使用）です。

参照ファイル

ファイル	参照するタイミング
references/pr-polish.md	コミットに fixup、WIP、「レビュー対応」などのノイズが含まれる場合、差分が 500 行を超える場合、またはユーザーが PR の整理、再構成、スカッシュ、分割を依頼した場合

ワークフロー

このチェックリストをコピーして進捗を記録します。

PR creation progress:
- [ ] Inspect the current branch and diff against the existing PR base, or the discovered default branch merge-base
- [ ] Existing PR? gh pr view --json url,state,isDraft (state OPEN means edit, not create)
- [ ] Linear ID from branch, commits, prompt, or issue link; no ID means no prefix
- [ ] Noisy commits or a >500-line diff? references/pr-polish.md, before pushing
- [ ] PR template present? Read it (paths under Templates)
- [ ] Draft title and body against Rules and Anti-patterns
- [ ] git push -u origin HEAD
- [ ] gh pr create (or gh pr edit); then gh pr view --json url,title and return the URL
- [ ] UI change with a video or screenshots? gh pr edit <n> --attach <file> after the final body, then gh pr view <n> --json body

先に説明文の承認をユーザーに求めないでください。目的はスピードです。書き直しを依頼された場合は、gh pr edit を実行します。

ルール

1. タイトル。 Linear ID がある場合：ABC-123: Add auth flow。ない場合：Add auth flow。60 文字未満とし、末尾にピリオドを付けません。リポジトリで PR タイトルのリント（.github/workflows/ 内の semantic-pull-request または commitlint ワークフロー）が行われている場合は、その形式に従い、ID は末尾に付けます：feat: add auth flow (ABC-123)。タイトル内の位置にかかわらず、ID に Linear のリンクを設定します。
2. 本文。 変更内容とその重要性を、短い段落 1 つで説明します。長さは変更内容に合わせます。1 行の修正なら、本文も 1 行で構いません。
3. 理由を捏造しない。 理由がプロンプト、Linear の課題、ブランチ、コミット、差分のいずれにも記載されていない場合は、作り上げずに省略します。
4. リスクと意見の募集は必要な場合のみ。 マイグレーション、課金、認証、権限、取り消し不能な書き込み、広範囲に及ぶ影響、または挙動の微妙な変更がある場合は、Risk: の行を 1 つ記載します。差分内の決定が未確定で、レビュアーの意見によって変わる場合は、Input wanted: の行を 1 つ記載します。決定事項を明記し、「意見歓迎」とだけ書かないでください。それ以外は何も記載しません。
5. テストの記載は実施した場合のみ。 実行した場合に限り、何を実行したかを記載します。Test plan セクションは作成せず、チェックボックスも使用しません。
6. 未完了の作業。 この PR で Linear の課題が完了しない場合は、タイトルに ID を含めず、本文に Part of ABC-123 と記載します。Linear の既定の自動化では、リンクされた課題は PR のマージ時に Done に移動します。このクローズしないための特別なキーワードを使うと、課題をリンクしつつクローズを防げます。
7. ドラフトとレビュアーは依頼された場合のみ。 「draft」または「WIP」の場合は --draft を指定します。後から昇格するには gh pr ready、ドラフトに戻すには gh pr ready --undo を実行します。--reviewer alice,org/team はユーザーが指定した人に限って使用します。CODEOWNERS により、オーナーにはすでにレビュー依頼が送られています。
8. 必要な内容を書いたら終える。 PR フッター（Generated with Claude Code、セッションリンク）はハーネスの attribution 設定が管理します。手動で追加せず、ハーネスまたはリポジトリのポリシーが追加したものも削除しないでください。フッターより上の部分がこのスキルの担当範囲です。1 段落の本文で、ハーネスの既定の Summary セクションと Test plan セクションを置き換えます。

アンチパターン：次の内容は書かないでください

• 成果物について説明する書き出し：「この PR は……を実装します」「この変更により……が保証されます」「このコミットでは……を導入します」
• 理由を伴わない変更履歴風の動詞：「Y を改善するために X をリファクタリングしました」「……に対応するために Z を更新しました」「包括的なテストカバレッジを追加しました」
• ファイル名やパスから始まる行。変更ファイルは差分にすでに記載されています。
• チェックボックス付きの Test plan セクション
• 差分を言い換えただけの箇条書き
• レビュアーが重要な点を探すために最後まで読まなければならない本文。要点が最初の文にない場合、その段落は説明ではなく要約です。

例

機能（ABC-123 は実際の Linear ID）

Title: ABC-123: Add auth flow with session management

Adds the auth flow needed for session-based login, including refresh, timeout handling, and a small error boundary for auth failures.

Input wanted: the 15-minute idle timeout is a guess; if product has a number, I'll use it.

バグ修正（実際のリスクと実際のテスト）

Title: PAY-482: Dedupe Stripe webhook retries

Stripe retries webhooks on timeout and our handler wasn't idempotent, so retried events created duplicate invoices. Now we record processed event IDs and skip repeats. Tested by replaying a captured retry sequence locally.

Risk: touches the billing write path.

雑務（Linear ID なし。差分以外に理由なし）

Title: Bump eslint to 9 and fix the new no-unused-vars hits

Bumps eslint to 9. The only code change is removing three unused imports it now flags.

最初の2つにはコミットから読み取れる本当の理由があるため、それだけを書いています。最初の項目にある Input wanted: は、タイムアウトがレビュー担当者の変更可能な判断事項であるため記載しています。2つ目の項目にある Risk: は、差分が請求処理の書き込みに触れているため記載しています。また、テストに関する文は、実際にリプレイを実行した場合にのみ含めています。3つ目にはこれ以上の理由がないため、あるかのようには書いていません。

テンプレート

GitHub は、.github/、リポジトリのルート、docs/ のいずれかにある pull_request_template.md（大文字小文字を区別しません）の最初の一致を読み込みます。また、複数のテンプレートを使う場合は、これらのいずれかにある PULL_REQUEST_TEMPLATE/ ディレクトリを読み込みます。gh pr create --body はテンプレートを完全にスキップするため、テンプレートがある場合はそれを読み、テンプレートの形式に沿って本文を作成してください。見出しを維持し、それぞれに1～2文で回答し、最初の見出しの下に1段落で説明を記載します。テンプレートで求められていない内容は追加しないでください。

PR の作成

ファイルツールを使って本文を一時ファイルに正確に書き込み、そのパスを --body-file に渡します。例では /tmp/pr-body.md を使っていますが、実行時にはタスクに応じた一時パスを選んでください。

まだ PR がない場合：作成

git push -u origin HEAD   # when creating a PR for local commits

gh pr create --title "ABC-123: Add auth flow" --body-file /tmp/pr-body.md

gh pr view --json url,title   # evidence the PR exists; return the url

ルール7が適用される場合は、ここで --draft または --reviewer を追加してください。--base を指定するのは、ターゲットがデフォルトブランチではない場合のみです。

PR がすでにオープンしている場合：タイトルと本文を更新

gh pr edit はタイトルと本文を全体的に上書きするため、差分ではなく、置き換える本文全体を作成してください。同じルールと避けるべきパターンが適用されます。

# A metadata-only edit does not push local commits.

gh pr edit --title "ABC-123: Add auth flow" --body-file /tmp/pr-body.md

gh pr view --json url,title   # confirm the update; return the url

UI の変更：ビジュアルを添付

ビジュアルの添付は任意です。差分によってユーザーに見えるもの（マークアップ、スタイル、文言、アセット）が変わり、短い MP4 または WebM、画像、あるいは変更前と変更後のペアがある場合は、レビュー担当者がブランチをチェックアウトせずに変更を確認できるよう、添付してください。最も適したものを選んでください。動きや一連の流れを示すなら動画、静的な変更なら画像、見た目の差分なら変更前と変更後を使います。本文にローカルファイルのパスを記載しても、添付ファイルにはなりません。

gh pr edit 42 --attach ./demo.mp4   # after the last body rewrite

# Before and after: label them in the body, where `**Before**` sits above
# `![Before](./before.png)`, and attach on the same call so gh swaps each
# local path for its uploaded URL. A `#Before` suffix is only alt text.
gh pr edit 42 --body-file /tmp/pr-body.md --attach ./before.png --attach ./after.png

gh pr view 42 --json body   # always, even after a non-zero exit

• 順序。 gh pr edit --body-file は、アップロード済み URL を含めて本文を置き換えます。最後の書き換えの後に添付するか、最終の --body-file と同じ呼び出しで --attach を渡してください（gh は本文内で参照されているローカルパスをアップロード済み URL に置き換え、それ以外の添付ファイルを追加します）。その後に書き換える場合は、読み戻した本文からアップロード済み URL を新しい本文ファイルにコピーしてください。
• 読み戻し。 ファイルごとに、アップロード済みの /user-attachments/assets/... URL（ホストは github.com、データレジデンシー対応の GHE Cloud では SUBDOMAIN.ghe.com）が本文に含まれている必要があります。動画は単独の行に URL のみを記載し、GitHub がプレーヤーとして表示できるようにします。画像は ![alt](...) の形式にします。一部のアップロードが失敗した場合でも、gh はアップロードに成功したファイルを使って PR を編集し、ゼロ以外の終了コードを返します。そのため、再試行する前に本文を読み戻してください。不足しているものだけを再添付し、何がアップロードできたかを報告してください。

注意点

• アップストリームがないブランチでの gh pr create：TTY では「どこにプッシュしますか？」というプロンプトで停止します。非インタラクティブなハーネスから実行すると、you must first push the current branch to a remote, or use the --head flag で中止されます。いずれの場合も、先に git push -u origin HEAD を実行してください。
• 非インタラクティブな gh pr create には、--title と --body（または --fill）の両方が必要です。指定しないと、must provide --title and --body (or --fill) when not running interactively で終了します。--fill はコミットメッセージをそのままコピーしますが、まさにそれを避けるためにこのスキルは変更履歴の本文を作成します。
• 本文やコミットメッセージを --body-file ではなくシェルのヒアドキュメントで渡す場合は、区切り文字を引用符で囲んでください（<<'EOF'）。引用符で囲まない <<EOF では、シェルがテキスト内のバッククォートや $vars を展開し、内容が壊れたりコマンドが実行されたりします。
• 見た目が似ている別々のエラーが2つあります。デフォルトブランチでは、gh pr create は must be on a branch named differently than "main" で中止されます。ベースブランチに対して新しい変更がないブランチでは、No commits between main and <branch> で失敗します。前者にはブランチが、後者にはコミットが必要です。
• ブランチにオープン中のPRがあると、gh pr create は a pull request for branch ... into branch main already exists で失敗します。まず gh pr view --json state を実行してください。OPEN の場合は gh pr edit を使います。結果が MERGED または CLOSED なら古いPRなので、新しいPRを作成してください。
• ブランチ名から Linear ID を大文字にして導き出してください。Linear のデフォルトのブランチ形式は username/abc-123-title-slug なので、mblode/abc-123-add-auth なら ABC-123 です。IDを推測してはいけません。Linear はタイトルに含まれるIDにPRを紐付けるため、間違ったIDを指定すると、他の人の課題が移動してしまいます。
• 通常の git diff では、コミット済みの変更は表示されません。実際のPRベースを指定して三点ドット形式の差分を使ってください。特にスタックされたPRでは、main を前提にしないでください。
• --attach の使用には、gh 2.99.0 以降（gh --version）、ユーザートークン（インストール用の ghs_ トークンではアップロードできません）、リポジトリへのプッシュアクセス（フォークから作成したコントリビューターのPRには添付ファイルを付けられません）、および github.com または GHE Cloud が必要です。GHES では添付ファイルを利用できません。これらの条件のいずれかを満たさない場合は、本文にローカルパスをリンクするのではなく、ビジュアルを添付できなかったことと、その保存場所を伝えてください。
• 最初のプッシュ前にコミットを再構成してください。オープン中のPRがあるブランチを強制プッシュして書き換えると、既存のインラインコメントに「古い」というマークが付き、レビュー担当者はそのスレッドを見失います。

関連スキル

• tidy：作成前に実行して、差分にバグがないか確認し、修正します。このスキルが編集するのはPRとそのコミットのみです。
• pr-babysitter：作成後に引き継ぎ、CI、競合、レビューコメントを監視します。
• autoship：npm リリースパイプライン（changesets、バージョンPR、公開）です。リリースの文脈なしで「リリースして」と依頼された場合は、こちらに振り分けます。

メンテナンス専用：evals/evals.json には、このスキルへの変更に対する回帰シナリオが含まれています。ユーザーのタスク中には読み込まれません。