pr

PR

自動生成された説明文を使って、プルリクエストを作成、更新、管理します。

アクションのルーティング

操作は組み合わせて実行できます。ユーザーが作成／更新の意図とともにレビュアー、ラベル、その他のメタデータを指定した場合、必要に応じて最初に PR を作成し、その後で各操作を適用します。

ユーザーの入力	アクション
/pr（テキストなし）	PR を作成または更新（Web インターフェース）
/pr this fixes the timeout bug	同じ操作を行い、説明文にコンテキストを追加
/pr against release/v2.x	指定されたベースブランチを対象に PR を作成
/pr close	gh pr close --delete-branch
/pr merge	gh pr merge --squash --delete-branch
/pr checks	gh pr checks
/pr status	gh pr view
/pr reviewers alice bob	必要に応じて PR を作成し、その後レビュアーを追加
/pr labels bug fix	必要に応じて PR を作成し、その後ラベルを追加
/pr web	gh pr view --web
/pr update	プッシュし、説明文を再生成
/pr rebase	gh pr update-branch
/pr context info, reviewers: alice, bob	コンテキスト付きで PR を作成し、その後レビュアーを追加
/pr only swift files	差分を一致するパスに限定
/pr ignore tests	一致するパスを差分から除外
/pr publish / /pr commit and push	ステージされていない変更を自動コミットし、その後プッシュ

意図が不明確な場合は、質問してください。

パスフィルター

ユーザーは包含／除外の glob パターンで差分の範囲を指定できます。自然言語（「swift のみ」「生成ファイルを除外」など）を git の pathspec に変換します。

• 包含 → *<pattern>（例：*.swift）
• 除外 → :!*<pattern>（例：:!*_test.go）

ステップ 1 のすべての git diff／git log 呼び出しで、-- セパレーターの後に追加してください。ステップ 2 の要約では有効なフィルターに言及し、ユーザーが確認できるようにします。

基本ワークフロー（作成／更新）

ステップ 1 — コンテキストを収集する

次の処理を並行して実行します。

ベースブランチを検出する（上から順に確認し、最初に一致した項目を使用します）。

1. 入力でユーザーが指定したベース
2. 既存 PR のベースブランチ（更新の場合）
3. Git 履歴 — git symbolic-ref refs/remotes/origin/HEAD でリモートのデフォルトを取得するか、git config init.defaultBranch を使用
4. 最後のフォールバック：gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

次にマージベースを計算します：git merge-base HEAD <detected-base>

差分とログ：

git diff --stat <base>...HEAD
git log --oneline <base>..HEAD

既存の PR を検出する：

gh pr list --head "$(git branch --show-current)" --state open --json number,url,title,isDraft,body,baseRefName --jq '.[0]'

これにより、既存の説明文とベースブランチも取得されます。

その他のコンテキスト：

• ブランチ名 → (?:^|[/_-])([A-Z]{3,}[A-Z0-9_]*-\d+) に一致するチケット ID を抽出します。重複を除き、並べ替えて、, で結合します。
• リポジトリテンプレートの検出（最初に一致したものを使用）：
  1. .github/pull_request_template.md
  2. .github/PULL_REQUEST_TEMPLATE/（ディレクトリ — 最も関連性の高いファイルを選択）
  3. .gitlab/pull_request_template.md
  4. .gitlab/merge_request_templates/（ディレクトリ）
• ワーキングツリーの状態 → git status --porcelain で未コミット／未プッシュの変更を検出します（ステップ 2 で提示します）。

ステップ 2 — 要約して確認

作業を開始する前に、次の要約を表示します。

• コミット: N 件のコミット、N 個のファイルを変更、+N/-N 行
• チケット: PROJ-123（または「検出されませんでした」）
• テンプレート: リポジトリのテンプレート／デフォルト／最小（およびその理由 — 以下の自動選択を参照）
• フィルター: include=*.swift、exclude=*_test.go（該当しない場合は行ごと省略）
• アクション: <base> に対して新しい PR を作成、または PR #42 を更新
• ブランチ: プッシュ済み／プッシュが必要／未コミットのファイル N 個／リモートより N 件先行したコミット

未コミットまたは未プッシュの変更がある場合は、明示してファイルを列挙します（最大約 10 個）。 ユーザーに次のどちらを行うか尋ねます。

1. 停止して、手動で対応してもらう
2. 自動でコミットしてプッシュする（ユーザーがすでに /pr publish などを指定している場合、または今確認した場合のみ）

続けてよいか尋ねます。「Proceed?」

ステップ 3 — 説明を作成

作成ルール

• ユーザーから提示されたコンテキストには、一字一句そのまま従います。
• 重要な変更だけに焦点を当てます。コメント、フォーマット、年の更新、誤字は省きます。
• PR には複数の課題が含まれる場合があります。重要度に応じて、すべて説明します。
• 技術的でありながら明確な表現にします。短い文を使い、箇条書きを優先します。
• 1 行ずつ分析せず、概要レベルで説明します。
• テンプレートの構成から逸脱しません。
• diff から意図や背景が明確でない場合は、コミットメッセージを参考にします。
• タイトルは簡潔に、5～10 語、72 文字未満にします。
• 余計なことは書きません。

テンプレートの選択（優先順）

1. 明示的な指定 — ユーザーが「最小テンプレートを使う」「デフォルトを使う」「リポジトリのテンプレートを使う」などと指定した場合。

2. 変更の重要度による自動分類（指定がない場合のデフォルト）：

   • 最小 — 誤字修正、フォーマット、コメント、ごく小規模な 1 行のバグ修正（約 20 行未満、1～2 ファイル）。
   • デフォルト（組み込み） — リファクタリング、依存関係の更新、中規模のバグ修正。
   • 検出済み — ステップ 1 で検出したリポジトリのテンプレート。重要な変更、新機能、破壊的変更に使用します。

   diff とコミットメッセージから重要度を判断します。ステップ 2 の要約で、選んだテンプレートとその理由を伝えます。

3. フォールバック — 組み込みの assets/default-template.md。

組み込みテンプレートは assets/default-template.md と assets/minimal-template.md にあります。

タイトル

• 主な変更を要約する簡潔なタイトル（5～10 語）を作成します。
• ブランチ名からチケット ID が見つかった場合は、タイトルの先頭に付けます：PROJ-123: <title>（複数の場合は PROJ-123,PROJ-456: <title>）。チケットが検出されなかった場合に限り、接頭辞を省略します。
• 既存の PR を更新する場合、ユーザーから再生成を依頼されない限り、既存のタイトルを維持します。

本文

• 何をしたかではなく、なぜ行ったかに焦点を当てます。
• 変更を領域ごとにまとめます。
• 破壊的変更は明示します。
• 出力から `` コメントを削除します。

更新の場合： 必ず既存の PR の説明を先に読みます（ステップ 1 で取得済み）。ユーザーが追加したコンテキスト、メモ、セクションは保持します。現在の diff に明らかに関係のない内容（例：現在は存在しないファイルや変更の説明）のみ削除します。自動生成された部分は、現在の diff に基づいて再生成します。

大規模な diff（500 行超）： まず --stat を使い、関連性の高いファイルの diff を選んで読み、残りは stat の出力から要約します。

手順 4 — 実行

1. 自動コミット（要求された場合） — ユーザーが公開を選択した場合：
   • 関連するファイルのみを名前で指定してステージングします（git add -A のような一括指定は避け、.env、認証情報、大容量のバイナリは決してステージングしないでください）。
   • ステージングされた差分に基づいて、72 文字未満の短い Conventional Commits 形式のメッセージ（feat:、fix:、docs: など）を作成します。
   • コミットしてから続行します。
2. 必要に応じてブランチをプッシュします：git push -u origin HEAD
3. 作成または更新します：
   • 新しい PR： gh pr create --web — ブラウザーを開くだけにしてください。gh pr create に --title や --body を渡さないでください。これらのフラグを指定すると CLI で作成されます。生成されたタイトルと本文をコンソールに出力し、ユーザーがブラウザーに貼り付けられるようにします。ユーザーが CLI での作成を明示的に希望した場合に限り、gh pr create --title "..." --body "..." を使用します。
   • 既存の PR： gh pr edit --title "..." --body "..."
4. ユーザーの入力に含まれる、レビュー担当者やラベルなどの複合操作を適用します。

レビュー担当者： 追加する前に、gh api で対応状況を確認します：

gh api repos/{owner}/{repo}/collaborators --jq '.[].login'

要求されたレビュー担当者がコラボレーターでない場合は警告します。

トラブルシューティング

• gh の認証がない： gh auth login を実行します
• HEAD がブランチに関連付けられていない： 先にブランチをチェックアウトします
• アップストリームリモートがない： git remote add origin <url>
• プッシュが拒否された： ブランチのリベースが必要な場合があります — git pull --rebase origin <base> を提案します