create-pull-request

プルリクエストを作成する

完了した変更を、レビュー可能な正確な GitHub プルリクエストとして公開します。

PR の作成依頼があった場合、必要に応じてブランチを作成し、対象範囲の変更をコミットし、強制プッシュせずにプッシュして、PR を作成するか、該当するオープン中の PR を更新する権限が与えられます。これらは確認を求めずに実行してください。この依頼では、マージ、自動マージ、強制プッシュ、履歴の書き換え、ラベル、レビュアー、担当者、Issue の編集、無関係な変更への対応は許可されていません。

次の場合に限り、作業を止めて報告してください。

• 変更が空、不完全、または所有者が明確でない変更と混在している
• 必須のチェックが失敗する、または実行できない
• 公開に失敗する

1. 変更内容を確認する

• リポジトリの指示、関連する場合はソース Issue、最近のコミットをいくつか読み、リポジトリの慣例を把握します。
• ヘッドは、ユーザーが指定しない限り現在のブランチです。ベースは、ユーザーまたはリポジトリの指示で指定されたブランチです。指定がなければ、リポジトリのデフォルトブランチを使用します。ヘッドがベースブランチである場合、または HEAD がデタッチ状態の場合は、変更内容にちなんだ名前のブランチを作成します。
• ベースブランチとのマージベース以降の差分全体に加え、ステージ済み、未ステージ、未追跡の変更を確認します。この変更に属するパスのみをステージします。公開作業のために stash、reset、clean、amend、rebase を実行してはいけません。
• このヘッドからこのベースへのオープン中の PR がある場合は、新たに作成せず、その PR を更新します。

2. 検証する

リポジトリで必須とされているチェックを実行します。必須のチェックが指定されていない場合は、変更された動作を検証する最小限のチェックと git diff --check を実行します。テスト対象のコードがその後変更されていない場合は、以前の結果を再利用します。チェックを通すためにテストを弱めたり、失敗する経路を回避したりしてはいけません。また、実行していないチェックを実行済みとして報告してはいけません。

3. コミットしてプッシュする

未コミットの対象範囲の変更を、リポジトリの慣例に沿ったメッセージで1つのコミットにまとめます。ヘッドブランチを強制プッシュせずにプッシュします。

4. タイトルと本文を書く

コミット済みの差分、ソース Issue、チェック結果に基づいて、タイトルと本文の両方を書きます。会話の内容は、変更に反映されている場合に限り、変更に関する判断や却下した代替案を説明するために使います。読者は、多くのプルリクエストをレビューするエンジニアです。ファイル名、コマンド、API など、正確な名称を示す技術用語のみを使い、平易な日常語で書きます。段落は短くし、最も重要な点を最初に書きます。コード識別子はバッククォートで囲みます。本文の長さは変更内容に見合ったものにします。

タイトル：レビュー担当者が PR を開かなくても理解できる、平易な言葉で成果を表します。「Webhook のロジックを更新」ではなく、「失敗した Webhook の配信をバックオフ付きで再試行」のようにします。

本文は次の順で記述します。

## Summary

Two to four sentences: what problem this solves, why it matters, and how behavior changes. A reader who stops here should know what the PR does. End with `Closes #N` when the PR fully resolves that issue in the same repository and targets the default branch, since GitHub closes linked issues only for those merges; otherwise reference it without closing it.

## Changes

The changes grouped by concern, each with the behavior before and after. Explain decisions a reviewer might question and the alternatives you rejected.

## How to review

Where to start, which parts need careful reading, and which are mechanical, such as renames, moved code, or generated files. Name any specific question you want the reviewer's judgment on.

## Verification

The commands run and their results, and manual checks with what they showed, such as how a UI change looks at each width checked. Say what was not tested and why.

## Risks and non-goals

What could break, such as compatibility, migrations, performance, or security; the known limits of a deliberately simple approach, such as "scans the HTML with patterns rather than parsing it, so logos inside nested `<template>` elements are missed"; and what this PR deliberately does not do. Reviewers and `babysit-pr` judge comments against this section, so name each limit and non-goal plainly.

Summary と Verification は必ず含めます。実際に記載する内容がある場合のみ、その他のセクションを追加します。1ファイルの修正であれば、通常はこの2つだけで十分です。「なし」とするセクションは書かないでください。

ファイルごとの変更一覧、差分の言い換え、未チェックのチェックボックス、秘密情報、ローカルの絶対パス、生のコマンド出力は含めないでください。

本文はリポジトリ外の一時ファイルに書き込み、--body-file で渡します。

5. 公開して報告する

該当するオープン中の PR がある場合は、必要に応じて gh pr edit で更新し、ドラフトであれば gh pr ready を実行します。それ以外の場合は、--repo、--base、--head（フォークの場合は OWNER:BRANCH）、--title、--body-file を明示して gh pr create を実行します。--draft は指定しないでください。作成に失敗した場合や出力が不明瞭な場合は、再試行する前に PR が存在するか確認します。

PR の URL、実行したチェックとその結果、未完了の CI チェックがあればそれを報告します。UI の変更の場合は、確認時に撮影したスクリーンショットを絶対ローカルパス付きの Markdown 画像として表示します。スクリーンショットは PR ではなく、この報告に記載します。PR はオープンのままにします。URL を受け取った後にユーザーから依頼された場合のみ、マージします。