my-create-draft-pull-request

次の手順でGitHubのDraft PullRequestを作成してください。

## 1. pushする

git pushがまだであれば `git push -u` でpushする。

## 2. PullRequestを作るための情報を収集する

- mainブランチとの差分を `gitro diff origin/main...HEAD` で確認
- `.github/pull_request_template.md` があれば参照する
- 今回のPRの変更種別をまず一言で把握する（例: リファクタリング / 機能追加 / マイグレーション / 設定変更 / ドキュメント更新 / バグ修正 / 依存アップグレード など）。この種別は、次の類似PR検索のキーワード選定に使う
- そのリポジトリでの自分のPRの書き方をお手本として学ぶ。できるだけ似た種別のPRを優先的に集める:
    1. 類似PRを優先的に探す (best effort): 今回の変更種別に関連するキーワード（機能名、変更ファイルの特徴的な識別子など）を使って、自分（@me）のマージ済みPRを検索する。例: `ghro pr list --author @me --state merged --search "<キーワード>" --limit 5`。`--search` はPR title/bodyのテキスト検索なので、そこにキーワードが乗らないPRは拾えない点に注意。結果から今回と似ているものを最大5件ピックアップする。1〜2件しか見つからなくても、空振りでも、取れたぶんを最優先のお手本として扱い、足りなければ (2) にフォールバックする
    2. 不足分を最新マージから補充: 類似PRが3件に満たない時のみ、不足分を `ghro pr list --author @me --state merged --limit <必要件数>` で最新マージ済みから補充する
    3. 自分のPRが3件に満たない場合のみ、他の人のPRも含めて集める
- 取得した各PRの本文を `ghro pr view <number>` で取得し、次の観点を観察してお手本とする:
    - 言語（日本語・英語・その他）
    - そのリポジトリのテンプレート・セクション構成の慣習
    - タイトルの規約（プレフィックスの有無、チケット番号の付け方、文字数、1行 vs 複数行 など）
    - 口調・文体（カジュアル / 中立 / 敬体）
    - 動機セクションの書き方と長さ
    - 動作確認セクションの書き方の傾向（粒度・フォーマット・情報量）
    - ファイル名・関数名・型名がどの程度の頻度で登場するか
- 類似PRがある場合は、分量・構造・動作確認の書き方の一次参考として特に重視する
- 情報が不足していたら、わたしに聞いてください

## 3. PullRequestを作成する

取得した情報をもとにPullRequestを作成する。わたしをアサインする (@meを使う)。

**大原則**: タイトル・description本文・動作確認セクションの書き方・分量は、手順2で観察した「自分のPR慣習」に沿わせる。類似PRがあればそれを一次参考にする。

- **テンプレートを忠実に使う**: `.github/pull_request_template.md` があれば、その見出し・セクション構成をそのまま踏襲する。テンプレの文字を勝手にエスケープ・改変しない
    - HTMLコメント (`<!-- ... -->`) は記入者向けのガイダンスであって、表示するコンテンツではない。**エスケープやコードフェンス囲みなどで可視テキスト化するのは、例外なく絶対にしない**。`<!-- -->` のまま渡せばGitHub上で非表示になるのが正しい挙動
    - 基本はテンプレ通り invisible な `<!-- -->` の形で残してよい。文脈次第で、コメントの指示に従って実際の値に置き換える・不要なものを削除する判断はありうるが、「見える形にする」ことだけは絶対に避ける
- descriptionの目的: レビュアーがdiffを読む前に必要なコンテキストだけを必要十分に伝える
- 基本の必須要素（ほぼ全てのPRで含める）:
    - なぜこの変更をしたか — 動機・背景。何の問題を解こうとしているか（例: 「◯◯のバグ報告があった」「◯◯の機能要望への対応」「関連リファクタの前段整備」）。関連チケット/PR/資料/議論ログへのリンクがあれば併記
    - 今回やったことのサマリ — diff全体を1〜3文に圧縮したもの。「変更したファイル・メソッドを列挙する」のとは違う
- 状況に応じて含める要素（該当する時のみ。無理に書かない）:
    - なぜその判断をしたか — 動機ではなく、他の選択肢もあり得た中で今回のアプローチを選んだ理由（例: 「A案/B案のうち、パフォーマンス優先でB案を採用」）。選択肢が1つしか無いような自明な変更では書かない
    - やらないと決めた範囲・意図的に残したもの — 読者が「なぜここは触らないのか」と疑問を持ちうる時のみ
    - 今回のスコープ — タスクが複数PRに分かれる時、今回がどこまでか
- **書かないもの**:
    - 変更したファイル・ディレクトリの一覧（diffで見える）
    - 追加/変更した関数・メソッド・フィールドの列挙（diffで見える）
    - diffを言い換えただけの「何が変わったか」の散文（自己チェック: その文をdiffと並べて読んだとき、diffから読み取れない新しい情報を伝えているか？ ノーなら削る）
    - AIの推測による「影響範囲」「注意点」（読者が実際に注意すべき非自明な話がある時だけ書く）
- backtickの使用は最低限にする。人間が書く時の手間と一貫性を優先する
    - backtickで囲むのは「コピペで実行するコマンド」「逐語性が重要な出力（エラーメッセージ等）」に限る
    - ファイル名・パス・関数名・型名などの識別子は、prose中では基本backtickなしで書く（`/` や `_` で視覚的に十分区別がつく）。多用するとコマンドや出力など本当に重要なbacktickが埋もれる
    - 識別子に言及してよい条件（設計意図・判断理由・変更範囲の理解に必要）と、backtickで囲むかどうかは別の判断
- **分量の原則**: PRの複雑度とリスクに比例させる。上限の目安は大原則どおり類似PRの分量。超えそうなら情報を削れないか見直す
- 動作確認セクション: 実施した確認を全列挙するのではなく、そのPRでレビュアーが安心するのに必要十分な情報だけを抽出する
    - 情報量は変更のリスクとレビュアーの確認コストに比例させる。軽微な変更なら短く、副作用や本番影響が大きい変更ほど実行結果・ログ・数値などを詳述する

## 4. PullRequestのURLを開く

`open` コマンドでPullRequestのURLを開く。

## 5. 特定の変更行単独への補足の提案（該当がある時のみ）

**デフォルトはスキップ**。「この行をこう直した理由」「ここは意図的にこうしている」など、PR description本文に書くには粒度が細かすぎる補足が実際にある時のみ、以下を提案する。該当がなければこの手順は出力しない。

**インラインコメントの投稿やコード編集は自分では行わない。あくまで提案のみ。**

- 「このファイル・行にインラインコメントを書くとレビュアーに伝わりやすい」候補の列挙
- その補足がコードを読む他者にも恒久的に有用なら、「コードコメントとして残すことを検討してはどうか」と併記