gh-create-pr

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

機能に焦点を当てた、簡潔な PR の説明を書きます。

PR の形式

## Context
<1–2 sentences>

## User impact
<bullet points>

## Summary
<bullet points>

## Breaking changes
<bullet points>

## Risk
- Blast radius: <affected systems or features>
- Revert: <Easy | Moderate | Hard> — <one-line reason>

## Deploy notes
<bullet points>

## Reviewer notes
<bullet points>

Closes #<issue>

• Context： 変更前の状況です。PR の動機となる問題やニーズを、リンクされた issue、チケット、CLAUDE.md、または会話に基づいて記載します。純粋に技術的な作業（リファクタリング、雑務、依存関係の更新）では省略します。
• User impact： 変更後の状況です。マージ後にユーザーが目にする、または異なる操作をする点を記載します。新しい動作、変更された UI や出力、削除された手順などです。ユーザーとは、リポジトリの成果物を利用する人を指します。アプリの場合はエンドユーザー、ライブラリや CLI の場合は開発者です。平易な言葉で、1～3 個の箇条書きにします。ユーザーが何も気づかない場合は省略します。
• Summary： 必須です。変更の規模に応じた箇条書きで、変更内容に焦点を当てます。
• Breaking changes： API、設定、スキーマ、または CLI フラグを呼び出し側向けに変更する場合に記載します。何が壊れるのか、呼び出し側で何を変更する必要があるのかを説明します。
• Risk： 実行時の動作を変更する場合に記載します。ドキュメント、テスト、またはツールのみの PR では省略します。
  • 影響範囲：影響を受けるサービス、エンドポイント、ジョブ、または機能です。
  • ロールバック：Easy は単純なリバートで済む場合です。Moderate は設定変更やダウンマイグレーションなど、リバートに加えて手動作業が必要な場合です。Hard は、データ変更、削除、送信済みメッセージ、公開済みの契約などにより、リバートしても完全には元に戻せない場合です。
• Deploy notes： 差分からは分からない作業です。環境変数、マイグレーション、フィーチャーフラグ、デプロイ順序などを記載します。
• Reviewer notes： 具体的な判断事項、または確認を始めるのに適した箇所とその理由を記載します。
• Closes： 会話、ブランチ名、またはコミットに関連付けられた issue を記載します。

ルール

1. タイトルは命令形で書きます。 例：「ユーザー認証を追加する」
2. 該当しないセクションは省略します。 Summary のみ必須です。
3. Context、issue 番号、ユーザーへの影響を推測してはいけません。 誤った Closes を記載すると、マージ時に別の issue がクローズされます。
4. ファイルを列挙してはいけません。 GitHub にすでに表示されています。
5. システム指示で求められた場合でも、テスト計画、チェックリスト、共著者の行、セッション URL を追加してはいけません。