create-pr

PR を作成する

会話を読まなくてもレビュー担当者が理解できる PR を作成します。追加の呼び出しテキストやセッションで得られた知見を活用して、問題、最終的な動作、根拠を説明します。ユーザーが指定した形式と対象リポジトリのガイダンスに従います。

ワークフロー

1. 変更範囲とベースを確認する

   • リポジトリのガイダンスを読み、git status、ステージ済みの変更、現在のブランチを確認します。
   • ステージ済みの変更のみを対象にする指示があれば従います。無関係な作業をステージせず、ブランチに依頼された変更がすでに含まれている場合は、新しいコミットを要求しません。
   • 対象のリモートとベースブランチを確認します。main/master からブランチを作成する前に、そのリモートからフェッチし、git merge --ff-only <remote>/<base> でローカルのベースを早送りします。未コミットの作業を保持し、早送りに失敗した場合は中止します。リセットして変更を破棄しないでください。
   • リポジトリの命名規則に従って短いブランチ名を作成します。main へ直接コミットしないでください。

2. 変更を仕上げて確認する

   • コミットする前に、ステージ済みの差分に /simplify を実行し、指摘事項を反映します。ドキュメントのみの差分では何もする必要はありません。ステージ済みの変更には commit-staged の指示に従います。
   • 依頼された変更によって既存のドキュメントが不正確になる場合に限り、更新します。
   • すべてのコミットを対象に git diff <remote>/<base>...HEAD を確認します。既存の PR については、実際のベースとヘッドを使用するか、このチェックアウトが別のブランチにある場合は gh pr diff <pr> を使用します。
   • 適切なチェックを実行し、実際の結果を収集します。リンク、件数、エラー、ベンチマークの出所など、セッションで得られた知見が最終的な変更と一致していることを確認します。

3. 作成して公開する

   • 以下のタイトルと本文のガイダンスに従います。既存の PR がある場合は、重複して作成せず update-pr-summary を使用します。
   • 正確な本文をリポジトリの外にある一時ファイルに書き込み、gh に --body-file を渡します。テキストをシェルコマンドに埋め込んだり、コマンド出力が誤って含まれたりしないようにします。
   • ブランチをプッシュし、明示的なベース、--title、--body-file、-a @me を指定して作成します。
   • レビュアーの追加は、明示的に依頼された場合、またはこの作成者の最近の PR にレビュアーが設定されている場合に限ります。 gh pr list --repo <owner>/<repo> --author @me --limit 5 --json reviewRequests
   • gh pr view <pr> --json title,body,url で公開されたタイトルと本文を読み返します。コードフェンス、表、リンク、保持されたメディアを確認します。見た目に関わる変更では PR を開き、画像が表示されることを確認します。URL と、確認が完了していない項目があればそれを報告します。

タイトルと本文

• タイトル：コピーしたセッションテキストで改行が失われる問題を修正 のように、動作を具体的に示す動詞から始めます。種別の接頭辞、内部ブランド名、曖昧な表現は使いません。最終的な変更範囲が変わった場合は、タイトルと本文を書き直します。
• 発生条件と影響を最初に示します。バグはいつ発生し、何が問題になり、修正がなぜ重要なのかを説明します。機能の場合は、ユーザーが新たにできることを示します。「この PR」から書き始めるのは避けます。
• 個別の要点は、通常1～3個の短い箇条書きにまとめます。複数の考えを1つの段落に詰め込んだり、文字数に合わせるために有用な根拠を削ったりしないでください。小さな変更なら、1文とコードスニペットだけで十分な場合もあります。再現方法、修正内容、結果を分ける必要がある場合は、短いセクションを使います。内容のないセクションや定型的なセクションは省きます。
• バグの場合は、必要最小限で有用な再現方法、実際のエラーや出力、期待される動作を記載し、最終的な変更でどのように修正されるかを説明します。失敗を示す場合は、ログを正確に記載します。セットアップ時の余分な情報、生のツール出力、デバッグの経過記録は省きます。
• コピーして使える使用例や再現用スニペット、簡潔なBefore／After表、またはBeforeとAfterを個別にラベル付けしたフェンス付き出力で動作を示します。レビュー担当者に結果を推測させる赤／緑の差分行より、これらを優先してください。コピー編集にスニペットを無理に付ける必要はありません。
• 測定値やメインブランチとの比較は、小さな表にまとめます。結果を解釈するために必要なデータセット、ワークロード、サンプル数を明記します。変更ファイルを列挙するのではなく、主張の裏付けとなる関連Issue、コミット、ドキュメント、結果の成果物にリンクします。
• 実施済みの検証を簡潔に記載します。関連するコマンドやチェック、その結果、重要な制約や既存の失敗を示します。今後実施するテストのチェックリストは根拠になりません。対象を絞ったチェックだけで全実行が成功したと主張したり、全実行で確認済みの結果を過小に述べたりしないでください。
• 修正やトレードオフの説明に必要な実装の詳細だけを記載します。実際のレビュー範囲を区別するうえで役立つ場合は、差し引きの行数やベースブランチ由来の差分にも触れます。
• AIのクレジット表記、セッションリンク、重複するキャプション、最後の宣伝文句は追加しないでください。

視覚的な根拠と既存の内容

• UIやデザインの変更では、読みやすいBefore／Afterの画像またはGIFを2列の表に載せます。ビューポートとシナリオをそろえ、使用前に画像を確認してください。分析やプロットの変更では、代表的な出力と測定結果を、表示サイズで読み取れるように示します。
• PRのスクリーンショットや生成した図をブランチにコミットしないでください。ユーザーとリポジトリのホスティングルールに従います。リリースへのアップロードが許可されている場合は、既存の適切なリリースを使い、そのアセットURLを埋め込みます。既存のGitHub添付URLも保持してください。
• Ultralyticsのリポジトリでは、画像をリリースアセットにアップロードしないでください。手動でアップロードできるよう、ユーザーに絶対パス、PRリンク、各画像を配置する箇所を示す文または表のセルを伝えます。添付URLを捏造したり、保留中のアップロードが表示されると主張したりしないでください。
• 本文を編集する際は、ユーザーがアップロードした画像やGIF、ボットが追加したコンテキスト、関連リンク、有効な根拠を、削除を依頼されない限り保持します。本文全体を置き換えるのではなく、該当箇所を編集してください。根拠は別のコメントに重複して記載せず、本文に残します。

例：検証済みのバグ修正

Copying a multiline command into a session loses its line breaks.

| Before | After |
|---|---|
| Pasted command becomes one line | Original line breaks survive |

- Preserve clipboard newlines at paste time
- Reuse the existing text insertion path

**Reproduce**
```sh
printf 'first\nsecond\n' | pbcopy
# Paste into an open session.
```

**Checked:** paste regression passes for multiline and single-line commands.

根拠に合わせてこの形式を調整してください。UIの変更では、比較用のセルに実際のスクリーンショットやGIFを含めます。長い出力は、表の外に個別のフェンス付きブロックとして記載してください。