Commit and PR

現在の変更を安全に公開し、レビュー可能な Pull Request を作成する。

PR 構成の判断

ユーザーやリポジトリが構成を指定している場合はそれを優先する。指定がなければ、エージェントが変更の依存関係、レビューの分けやすさ、各段の検証可能性、親の更新に追従する手間を見て通常の PR と stacked PR を選ぶ。stacked PR の明示的な依頼は必要なく、採否や明確な分割境界の承認だけを求めて作業を止めない。採用する場合は、その理由と各 PR の役割・依存順を簡潔に伝えて進める。

行数・ファイル数・コミット数だけで分割しない。各段は親までの変更を含む状態で動作・検証できる単位にし、その変更を検証するテストも同じ段に含める。既存 stack の作成・更新を行う場合、または新しく stacked PR を選んだ場合は、stacked PR の手順を読む。

ワークフロー

1. 作業ツリー、差分、現在のブランチ、リモート、リポジトリ固有の指示・PR テンプレートを確認し、今回含める変更と公開先リポジトリを特定する。
2. 上記の基準で PR 構成と今回更新する範囲を決める。デフォルトブランチまたは保護ブランチ上にいる場合は、変更内容に合う作業ブランチを作成する。既存の作業ブランチは、目的が今回の変更と一致する場合にそのまま使う。stack に新しい段を追加する場合は親と別のブランチを用意する。各 PR について、実際にプッシュする head（リポジトリ・所有者・ブランチ）を確定する。
3. 各 repo・head の open PR を調べてから base を決める。PR ごとの明示的な base 指定を優先し、stack 全体の統合先の指定は最下段に適用する。未指定で既存 open PR が一意ならその base を引き継ぐ。既存 PR がなければ、stack の子 PR は確定した親の head ブランチを使い、通常の PR または新規 stack の最下段は公開先の既定ブランチを使う。複数候補があり依頼と依存関係から確定できない場合だけ確認する。
4. 未コミットの対象変更がある場合だけステージし、ステージ済み差分を確認する。秘密情報、認証情報、意図しない生成物、無関係なユーザー変更は含めない。作業ツリーがクリーンでも、対象ブランチの未公開コミットと確定した base からの全体差分を確認して続行する。
5. 変更に応じた検証を行い、結果を記録する。失敗を解消できない場合は、成功したように扱わずユーザーへ伝える。
6. 未コミットの対象変更があれば、定められたフォーマットで適切な単位のコミットを作成する。コミット済みの場合は空コミットを追加しない。
7. 必要なコミットを対象リモートにプッシュする。以下の既存 PR の確認手順に従って PR を作成または更新する。複数の PR は各段について手順 4〜7 を行い、依存順に公開する。内容は各 PR の base からの全体差分と実施した検証に基づき、事実を正確に記載する。
8. PR の URL と、レビュー時に知っておくべき検証結果や残課題を返す。stacked PR は依存順に URL を並べ、各段の役割を添える。

既存 PR と再実行

• base の確定前に、公開先リポジトリを明示して対象 head の PR を調べる。この初回照会では base で絞り込まず、既定ブランチ以外への PR も取得する。ブランチ名だけで判断せず、head のリポジトリ・所有者・ブランチ、base ブランチ、open/closed/merged の状態を確認する。fork からの PR は head と base のリポジトリが異なる点に注意する。
• repo・head・base が一致する open PR があれば、新規作成せずその PR を更新する。プッシュが必要な場合は反映後の head を確認し、最終差分に合わせてタイトル・本文を整える。ユーザーが追加した有効な背景やレビュー情報は保持する。
• 同じ head でも base が異なる PR を、無断で別 base に変更しない。複数候補があり依頼から対象を確定できない場合に限り確認する。closed/merged の PR は再利用せず、今回の base との差分に対して新規 PR が必要かを判断する。
• 未公開コミットがあればプッシュし、プッシュ済みでも対象 PR が未作成なら作成する。再実行時に PR 作成の応答が不明だった場合は、既存 PR を再照会して重複作成を防ぐ。
• 作業ツリーの差分がないことだけで終了しない。対象コミットが公開済みで、対象 PR も現在の差分を反映済みなら、その URL と状態を返す。base との差分も公開すべき変更もなければ、空の PR を作らずその旨を報告する。

フォーマット

コミットメッセージ

書式と言語は PR と同じ優先順位に従う。指定がない場合、コミットメッセージは、1行目に変更内容を端的に表す日本語の要約を書き、空行の後に2行目以降で含まれる変更を箇条書きにする。

<変更内容の要約>

- <含まれる変更1>
- <含まれる変更2>

PR

PR タイトルは base から head までの変更全体を表す要約にし、言語は下記の優先順位に従う。単一コミットならその要約を使ってよい。複数コミットでは直近のメッセージを流用せず、コミット一覧と全体差分から目的・結果をまとめる。

ユーザーの明示指定、リポジトリ固有の指示・PR テンプレート、このスキルの既定書式の順に優先する。テンプレートがある場合は、その見出し・必須項目・チェックリストを保持し、以下の背景・変更・レビュー観点・検証情報を対応する項目へ記載する。言語指定がなければ日本語を使う。

テンプレートなどの指定がない場合は、次の見出しを順番どおりに使用する。該当する内容がない場合は なし と記載する。

## 背景・目的
<変更が必要になった理由>

## 変更内容
- <主な変更点>

## レビューのポイント
- <確認してほしい点>

## 検証
- [x] <実行した検証>
- [ ] <未実行の検証または残課題>

制約

• 空コミットや空の PR を作らない。未コミット変更・未公開コミット・base との差分・既存 PR の状態を区別して判断する。
• 複数行の PR 本文を CLI に渡す場合は、一時ファイルへ実際の改行を含めて書き、--body-file などで渡す。
• force push はユーザーの明示的な許可を必要とする。ただし、stacked PR の変更追従に必要な --force-with-lease は確認なしで実行してよい。例外は対象 stack の作業ブランチを親の更新・マージや統合先ブランチの更新に追従させるための rebase と再公開に限り、確認したリモート head を期待値として使う。詳細は stacked PR の追従手順に従う。
• 検証フックの回避と公開済みコミットの amend は、ユーザーの明示的な許可なしに行わない。上記の例外を通常の --force や追従に無関係な履歴整理へ広げない。
• 対象変更が曖昧で、無関係な変更を巻き込む可能性がある場合は、コミット前に確認する。
• 認証、権限、競合、必須チェックなどで公開を完了できない場合は、既に完了した操作と阻害要因を明確に報告する。