my-create-draft-pull-request

name	my-create-draft-pull-request
description	GitHubのDraft PullRequestを作成する
allowed-tools	Bash(git push:*), Bash(open:*)
user-invocable	true

次の手順で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 3。--search はPR title/bodyのテキスト検索なので、そこにキーワードが乗らないPRは拾えない点に注意。結果から今回と似ているものを最大3件ピックアップする。1〜2件しか見つからなくても、空振りでも、取れたぶんを最優先のお手本として扱い、足りなければ (2) にフォールバックする
  2. 不足分を最新マージから補充: 類似PRが1件以下の時のみ、不足分を ghro pr list --author @me --state merged --limit <必要件数> で最新マージ済みから補充する（合計3件を目安に）
  3. 自分のPRが1件以下の場合のみ、他の人のPRも含めて集める
• 取得した各PRの本文を ghro pr view <number> で取得し、次の観点を観察してお手本とする:
  • 言語（日本語・英語・その他）
  • そのリポジトリのテンプレート・セクション構成の慣習
  • タイトルの規約（プレフィックスの有無、チケット番号の付け方、文字数、1行 vs 複数行 など）
  • 口調・文体（カジュアル / 中立 / 敬体）
  • 動機セクションの書き方と長さ
  • 動作確認セクションの書き方の傾向（粒度・フォーマット・情報量）
  • ファイル名・関数名・型名がどの程度の頻度で登場するか
• 類似PRがある場合は、分量・構造・動作確認の書き方の一次参考として特に重視する
• 情報が不足していたら、わたしに聞いてください

3. PullRequestを作成する

手順2で集めた情報をもとに、まずPRの下書きを作り、まっさらなSubAgentでレビューしてから実際に作成する。

3-1. 下書きを作る

手順2で観察した情報をもとに、PRのタイトル・description本文・動作確認セクションの下書きを作る（この段階ではまだPRは作成しない）。

大原則: タイトル・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でレビュアーが安心するのに必要十分な情報だけを抽出する
  • 情報量は変更のリスクとレビュアーの確認コストに比例させる。軽微な変更なら短く、副作用や本番影響が大きい変更ほど実行結果・ログ・数値などを詳述する

3-2. まっさらなSubAgentで下書きをレビューする

3-1の下書きを書いた本体は、diffや会話の文脈に引きずられ、自分の文章の逸脱に気づきにくい。会話文脈を引き継がないまっさらなSubAgentを起動し、原則とお手本だけを渡して下書きを客観的にレビューさせる。毎回必ず実行する（軽微なPRでもスキップしない）。

SubAgentには次の情報を渡す（SubAgentは文脈を持たないため、必要なものは全て明示的に渡す）:

• 3-1で作った下書きのタイトルと本文
• .github/pull_request_template.md の内容（あれば）
• 手順2で集めた類似PR（自分のPR慣習のお手本）のテキスト
• gitro diff origin/main...HEAD のdiff（サマリの妥当性と「書かないもの」混入のチェックに使う）
• 3-1の原則（大原則・テンプレ忠実・必須要素・書かないもの・backtick・分量・動作確認）。チェック観点として丸ごと渡す。要約・抜粋せず原文のまま渡すこと

SubAgentは渡した3-1の原則に照らして下書きを点検し、修正は行わず、原則から逸脱している点とその修正提案だけを返す。

3-3. レビュー結果を反映してPRを作成する

SubAgentの指摘を批判的に評価し（指摘が常に正しいとは限らない）、妥当なものを下書きに反映する。その上で、整えた下書きでDraft PullRequestを作成する。わたしをアサインする (@meを使う)。

4. PullRequestのURLを開く

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

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

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

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

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