create-pr

PR の作成

忙しい開発者向けに、詳細を加える前に変更内容とその目的を明確にします。

現在のテンプレートを読む

• 毎回、リポジトリで該当する PR テンプレートを見つけて読みます。HTML コメント、リンク先のガイドライン、コントリビューションの手順も含めて確認します。リポジトリのルート、.github/、docs/ を確認し、テンプレート用ディレクトリも調べます。テンプレートが複数ある場合は、変更に合ったものを選びます。
• テンプレートの現在のセクション、順序、長さの制限、チェックリストの指示に従います。このスキルにテンプレートの構成をコピーしたり、記憶している古いバージョンを再利用したりしないでください。
• 他のガイダンスに古い構成のコピーがあっても、実際に現在使われている PR テンプレートを優先します。ただし、両立するコントリビューション規則には従います。
• ローカルにテンプレートがない場合は、対象リポジトリと GitHub の共有デフォルトを確認します。どちらにもない場合は、変更に合った簡潔な構成を使い、テンプレートが見つからなかったことを伝えます。
• 意図したベースブランチとの差分全体と、関連する Issue の背景を確認します。作業の手順や断念した方法ではなく、最終的な変更を説明します。

説明を書く

以下の内容は、決まった見出しを追加するのではなく、テンプレートの適切なセクションに収めます。

• 変更内容の短い要約と、その重要性から説明を始めます。テンプレートでリンクやメタデータが先に指定されている場合は、その順序を維持し、最初の説明セクションを要約から始めます。
• 短く簡潔な英語と、具体的な動作を使います。詳しい技術情報は後半に記載し、テンプレートで許可されている場合や、レビュー担当者に必要な場合に限ります。
• バグ修正の場合は、元の問題を再現するための設定と手順、期待される動作、修正前に確認された動作、そして修正によってその差がどう解消されるかを記載します。簡潔な例で表現する場合も、各項目を明確に分けてください。実際に再現していない問題を再現したと主張しないでください。未確認の手順には、その旨を明記します。
• 実装方針について、重要な判断と、それによって意図した動作がどう実現されるかを簡潔に記載します。レビューやユーザーに影響する場合に限り、トレードオフや影響にも触れます。
• 再現手順、修正前後の動作、方針、影響を文章より明確に説明できる場合は、小さな図やコード例を検討します。焦点を絞ったスニペットや Mermaid 図を優先し、本文を繰り返すだけの図は省きます。テンプレートの長さの制限を守ります。
• 検証セクション、コマンドログ、実行したチェックやテストの一覧は追加しません。コードベースに追加したテストと、そのテストが対象とする動作については、簡潔に触れてもかまいません。この制限は説明文に関するものです。リポジトリで必須とされるチェックは、引き続き実施してください。
• 必須のチェックリスト項目は残し、事実に沿ってチェックします。テンプレートで検証セクションや実行結果が明示的に必須とされている場合は、指定された見出しやフィールドを残します。ただし、ユーザーの希望に従い、コマンドやテストの実行報告は省きます。この具体的な矛盾については、PR の外でユーザーに説明します。

関連作業へのリンク

• 関連する Issue と PR は、テンプレートのリンク用セクション、または最も近い既存のセクションに記載します。適切なセクションがない場合は、ガイドラインで許可されているときに限り、簡潔なリンク用セクションを追加します。
• 依頼に Linear チケットが含まれている場合は、そのセクションに記載します。提示された URL を使うか、利用可能なコンテキストやツールで ID を解決します。ワークスペースの URL を捏造してはいけません。
• この PR で実際に解決する Issue に限り、クローズ用キーワードを使います。その他の Issue、チケット、PR は、クローズするかのように示さず、関連作業または依存関係として記載します。
• リンクや Issue 番号を捏造してはいけません。必須のリンクを特定できない場合は、不足している情報を尋ねます。関連作業がわからない場合は、空欄の扱いに関するテンプレートの規則に従います。

PR を作成する

• タスクとリポジトリのコンテキストから、対象のリポジトリ、ベースブランチ、変更範囲を確認します。ユーザーがドラフト PR と通常の PR のどちらを希望しているかに従います。
• PR の作成が依頼されている場合は、利用可能な GitHub ツールまたは gh を使って最後まで実行します。説明文のみを求められている場合は、公開せずにドラフトを返します。コミットやプッシュはユーザーの許可範囲内でのみ行い、無関係な変更は含めないでください。
• 公開する前に、完成した説明文をすべてのテンプレートのセクションと指示に照らし合わせて確認します。記載内容が差分と一致していること、リンクが正確であること、プレースホルダーが残っていないことを確認してください。
• gh を使う場合は、正確な Markdown を一時ファイルに書き込み、改行とコードをそのまま保持できるように --body-file を使用します。
• 作成する前に、そのブランチの既存 PR を確認します。作成結果が不明確な場合は、重複を避けるため、再試行する前に作成が成功していないか確認します。認証または権限の問題が解決しない場合は、繰り返し再試行せず、その問題を報告します。
• PR のリンクを返し、ユーザーにレビューを依頼します。実行結果と未解決の問題は、PR の説明文には含めず、タスクへの回答に記載します。