pr

現在のブランチに対して、GitHub のプルリクエストを 1 件作成または更新します。プルリクエストは、長期的に参照できる知識の引き継ぎとして扱います。変更された動作とその理由を説明し、ファイルの一覧にはしないでください。まずユーザーの明示的な指示に従い、次に適用されるリポジトリのガイダンスに従ってから、以下のデフォルト設定を適用します。タイトルは英語で記述してください。本文は、ユーザーが明示的に指定した言語で記述します。指定がなければ、ユーザーの依頼と同じ言語で記述してください。このスキルでは、本文の言語を固定していません。ユーザー向けの応答は、ユーザーの言語で記述してください。

1. 調査と確認

1. 内容を作成する前に、適用されるリポジトリのガイダンスとプルリクエストのテンプレートを読みます。

2. 現在のブランチとワークツリーを調査します。

   git branch --show-current
   git status --short --branch
   git symbolic-ref --quiet --short refs/remotes/origin/HEAD
   

   シンボリック参照の結果は、新しいプルリクエストを作成する場合のフォールバック先としてのみ保持します。ブランチ名は、先頭の origin/ だけを削除して取得します。以下のプルリクエスト検索が完了するまで、比較参照を選択しないでください。

3. git fetch --prune origin でリモート参照を更新します。フェッチに失敗した場合は、エラーを表示して停止します。古いリモート状態に基づいて公開の判断をしないでください。

4. 正確に一致する head ブランチのオープン中のプルリクエストを検索します。

   gh pr list --head <branch> --state open --limit 1 \
     --json number,title,url,body,isDraft,baseRefName,headRefName
   

   コマンドが失敗した場合は、エラーを表示して停止します。結果は後で使用できるように保存します。空の配列なら作成し、結果が 1 件なら更新します。

5. 検索が完了してから、有効な base を選択します。

   • 既存のプルリクエストがある場合は、その baseRefName を使用します。ユーザーが別の base を明示的に指定した場合は、どちらかを黙って比較に使用せず、停止して確認します。
   • 新しいプルリクエストの場合は、ユーザーが base を指定していればそれを使用し、指定がなければリモートのデフォルトブランチを使用します。どちらも利用できない場合は、停止して base を尋ねます。

   指定された origin/<base> は、先頭の origin/ だけを削除して正規化し、その後 <comparison-ref> を origin/<base> に設定します。フェッチ後、その参照が存在することを確認します。現在のブランチが有効な base と同じ場合、または git log <comparison-ref>..HEAD --oneline にコミットが含まれていない場合は停止します。

6. 追跡対象または未追跡の変更がある場合、それらはプルリクエストに含まれないことをユーザーに伝え、先にコミットするか確認します。ユーザーがコミットするか、変更を含めないことを明示的に選択した後にのみ続行します。

7. 次のコマンドでアップストリームを確認します。

   git rev-parse --abbrev-ref --symbolic-full-name '@{upstream}'
   

   • アップストリームがない場合は、git push -u origin <branch> を実行します。
   • アップストリームがある場合は、git rev-list --left-right --count <upstream>...HEAD を実行して比較します。左側の件数が 0 以外の場合は停止し、ローカルブランチの同期が必要であることを報告します。暗黙的にマージ、リベース、強制プッシュをしないでください。右側の件数だけが 0 以外の場合は、git push を実行します。
   • プッシュに失敗した場合は、エラーを表示して停止します。--force を付けて再試行してはいけません。

2. PR モデルを構築する

保存済みの PR 検索結果と、上記で選択した有効な <comparison-ref> を使用して、 すべての PR コミットと PR の完全な差分を調べます。

git log <comparison-ref>..HEAD --format='%h%x09%s%n%b'
git diff --stat <comparison-ref>...HEAD
git diff <comparison-ref>...HEAD

本文の深さの選択、主張の作成、変更の網羅性の確認、コミット数とファイル数の報告では、これらの出力のみを PR の変更セットとして扱います。以降の手順で「ブランチコミット」とは、git log <comparison-ref>..HEAD が返すコミットのみを指します。<comparison-ref> から到達可能なコミットは、リモートのデフォルトブランチに存在しない場合でもベースの履歴であり、その動作を本文に含めてはいけません。

コミット履歴は根拠として使用し、説明の構成には使用しません。完全な PR 差分で置き換えられる中間状態は無視し、最終的な動作をまとめます。下書きを作成する前に、重要なワークフローまたはコンポーネントをそれぞれ切り分け、根拠のあるアクター、トリガー、入力と時間的な範囲、状態または出力、後続への引き継ぎ、失敗時の動作、該当する場合はロールアウトまたは移行の順序を整理します。すべての重要なブランチ変更が含まれていることを内部で確認しますが、その確認内容を時系列のコミット一覧として公開してはいけません。

保持した根拠から、変更前後の主要な動作を特定します。理由、意味上の説明、影響、制約、トレードオフ、リスクを含めるのは、根拠がその具体的な関連性を裏付けている場合に限ります。関連する変更から推測するのではなく、根拠がなければ省略します。保存済みの検索結果が空なら新規作成し、結果が1件ならその PR を更新します。

3. 根拠に基づく内容を作成する

新規 PR のタイトル

• 簡潔な英語の命令形動詞で始め、中心となる動作を示します。
• チケットの接頭辞を除き、タイトルは40文字以内にします。
• ブランチに、英字または英数字の後にハイフンと数字が続く識別子が含まれている場合は、大文字にして角括弧で囲み、先頭に付けます。たとえば、feature/proj-42-fix-layout は [PROJ-42] Fix layout になります。
• 既存の PR のタイトルは変更しません。

本文の深さ

コミット数と変更ファイル数を数え、2つの指標が一致しない場合は、より詳細なレベルを使用します。

レベル	基準	生成するセクション
シンプル	コミット1～2件、ファイル3件以下	概要、変更点
標準	コミット3～10件、またはファイル4～10件	概要、主な変更点、検証
複雑	コミット11件以上、またはファイル11件以上	概要、テーマ別の主な変更点、検証、レビュー時の注意点

リポジトリのテンプレートで必須セクションが追加されていても、本文の分量は適切な範囲に保ちます。次の内容ルールを適用してください。

• 動作が変更前から変更後にどう変わるか、そしてその変更が重要な理由を冒頭で示します。
• PRの大部分を説明する、核となる直感を1つ示し、補足の変更を動作またはレビュー時の懸念ごとにまとめます。重要なワークフローが、根拠のある理由や結果を共有していない場合は、無理に包括的な説明にまとめず、変更前後の説明を分けてください。本文をコミット順に並べたり、ファイルごとの説明にしたり、差分の各部分を繰り返したりしないでください。
• メンタルモデルを変える、またはレビュー担当者の対応が必要となる場合を除き、二次的または機械的な編集はSummaryとKey Changesから省きます。定型的なテスト実装を主な変更点として列挙するのではなく、テストコマンドと結果はValidationに記載してください。
• 具体的な入力、状態、出力によって、直感的でないルールをより手短に説明できる場合は、最小限の例を1つ使います。たとえば、Requests r1, r1, r2 used to create three jobs; they now create two because request ID defines identity.のように記載できます。動作は差分に忠実に説明し、文章のほうが明確な場合に例を無理に使わないでください。
• ユーザーまたはリポジトリのテンプレートで明示的に要求されない限り、コミットハッシュとコミットごとのログは省きます。
• 根拠がある場合に限り、検証結果を報告します。コミット履歴にのみ記載された結果は、その旨を明記してください。変更されたテストや静的な調査を、実行済みの検証結果として記載しないでください。報告されたチェックで検証されていない、重要なランタイム、統合、デプロイ、移行、外部サービスとの境界を明記してください。必須の検証セクションがあり、実行されたチェックの根拠がない場合は、Not runに相当する表現を記載してください。推測はしないでください。
• 差分が裏付ける場合に限り、移行に関する注意事項、リスク、またはレビュー時の指針を記載します。

生成した内容のみを、次の正確な所有範囲マーカーで囲みます。

<generated sections>

更新する場合：

• 両方のマーカーがそれぞれ1回ずつ、正しい順序で存在する場合は、マーカーで囲まれたブロックのみを置き換え、範囲外のテキストはバイト単位でそのまま保持します。
• 本文にマーカーがない場合は、既存の本文全体をバイト単位でそのまま保持し、マーカーで囲んだ生成ブロックを1つ追加します。
• マーカーの形式が正しくない、重複している、または順序が逆の場合は、作業を中止し、ユーザーに進め方を確認します。ユーザーが作成した内容を誤って削除しないでください。

作成時にユーザーがドラフトを希望した場合、またはブランチ名がdraft/またはwip/で始まる場合は、--draftを追加します。本文の更新時は、既存のドラフト状態を維持します。

4. 検証、実行、確認

gh pr createまたはgh pr editを実行する前に、次の点を確認してください。

1. 作成するタイトルが、言語、長さ、動詞、チケットに関するルールを満たしていること。
2. 本文が選択した深さに合い、核となる直感から始まり、時系列のコミット一覧に頼らず、ブランチの重要な変更をすべて網羅していること。
3. すべての事実の記述が、確認した差分、履歴、ガイダンス、またはテンプレートに基づいていること。
4. 所有範囲マーカーの外側にある既存の内容が変更されていないこと。

シェルによる展開で本文が変わらないように、標準入力経由で本文を渡します。

gh pr create --title "<title>" --assignee @me --base "<base>" \
  --head "<branch>" [--draft] --body-file - <<'EOF'
<body>
EOF

gh pr edit "<number>" --body-file - <<'EOF'
<body>
EOF

角括弧付きの任意フラグをそのまま記載しないでください。--draftを追加するか、省略してください。成功したら、gh pr view <number-or-url> --json number,title,url,body,isDraft,commits,filesを実行し、公開されたタイトル、本文、ドラフト状態、コミット数、ファイル数を確認します。作成、更新、または検証に失敗した場合は、エラーを表示して作業を中止し、成功したと主張しないでください。

PR番号とタイトル、URL、作成または更新の状態、ドラフト状態、コミット数、変更ファイル数を報告してください。