commit

コミット

このスキルを使って、無関係な変更を取り込まずに、依頼された変更を 1 つ以上のきれいなコミットにまとめます。

対象範囲

• デフォルト： 現在のタスクで現在のエージェントが行った変更のみをコミットします。既知の開始時点の状態、会話、ツールの履歴から変更の所有者を判断してください。現在の差分やファイルパスだけから推測してはいけません。
• すべての変更： ユーザーがすべて、全変更、またはツリー全体のコミットを明示的に依頼した場合に限り、作業ツリー全体を確認してコミットします。
• 明示された一部： ユーザーが指定したファイル、ハンク、コミット、除外事項に従います。
• 一時的な成果物： 調査のみを目的とした診断情報、ログ、トレース、プロファイラーの出力、実験用トグル、スクリーンショット、再現用フィクスチャは、明示的に依頼されない限り除外します。恒久的な回帰テストは残します。不明な場合は確認してください。
• 変更の所有者や依頼された範囲を確実に判断できない場合は、ステージングの前に停止して確認してください。推測で既存の変更、並行作業による変更、ユーザーが作成した変更を含めてはいけません。

承認モード

• 直接モード： ユーザーがコミットを依頼した場合は、依頼された範囲を分析し、別途「進めてよいか」を尋ねずに、必要なコミットを作成します。
• 計画モード： ユーザーが計画を求めた場合、事前にコミットの確認を求めた場合、待つよう指示した場合、コミット前に確認するよう求めた場合、またはその他の方法で事前承認を求めた場合は、コミット計画を提示し、go などの明示的な承認を待ってからステージングまたはコミットします。承認後は、作業ツリーに予期しない変更がない限り、再確認を求めず、合意済みのコミットをすべて作成します。
• 確認による停止： どのモードでも、所有者が不明確な場合、混在したハンクを安全にステージングできない場合、リポジトリのガイダンスがユーザーの依頼と矛盾する場合、または意図されたグループ分けが曖昧で、コミットするとユーザーの意図を損なうおそれがある場合は、コミット前に停止してください。
• 承認への応答： 前のターンでコミット計画を提示し、ユーザーが今回 go と返した場合、その計画への承認として扱います。ステージングの前に作業ツリーを再確認してください。

確認

1. まずリポジトリのガイダンスを読みます。AGENTS.md、コントリビューション文書、確認できるコミット規約などを確認してください。
2. 既知の GitHub Issue に対応する作業かどうかを、ユーザーが明示したコンテキスト、承認済みの Issue／タスク文書、検証済みの Issue URL、またはリポジトリのメタデータから判断します。偶然一致した番号だけを根拠に、Issue との関連性を推測してはいけません。
3. git status -sb、git diff --stat、git diff --staged --stat、対象を絞った git diff／git diff --staged で状態を確認します。ステージング前に、関連する未追跡ファイルも確認してください。
4. ステージ済み、未ステージ、未追跡の変更を対象内または対象外に分類します。タスクの所有権があるからといって、それだけで変更が対象に含まれるわけではありません。タスクで作成した計測機能やフィクスチャは、ステージング前に恒久的なものか一時的なものかを分類してください。ツリー全体は状況を把握するためのものであり、すべての変更をコミットする許可ではありません。
5. 対象外のステージ済み変更は保持してください。対象の変更が完全に管理できるパスにある場合は、パスを限定したコミットによって、無関係なインデックス項目をそのまま残せます。対象と無関係なハンクが同じパスにある場合や、安全に分離できるか不明な場合は、他者の変更を取り消したりコミットしたりせず、停止して確認してください。
6. デバッグログや生成物など、ユーザーがコミットしないよう明示した除外対象を守ります。除外した変更はステージングせずに残し、その後ユーザーに報告してください。
7. 対象内の変更がない場合は、その旨を伝え、残っている対象外の変更があれば、コミットせずに報告してください。

グループ分け

対象内の変更を、機能、修正、リファクタリング、テスト、ドキュメント、設定、依存関係、サブシステムなど、まとまりのある概念ごとにグループ化します。別々にレビュー、取り消し、説明するのが適切な変更は、別々のコミットにすることを優先してください。

1 つのファイルに無関係な変更が含まれている場合は、git add -p など、パスまたはハンクを限定する方法で分割してステージングします。同じファイルにあるという理由だけで、無関係なハンクを 1 つのコミットにまとめてはいけません。

メッセージのスタイル

ユーザーからの明示的な指示や、リポジトリまたはワークスペースのガイダンスがある場合はそれに従ってください。これらは、このスキルの既定の方針より優先されます。それ以外の場合は、次の既定の方針に従ってください。

• Conventional Commit の type: subject 形式
• スコープを括弧で付けない
• 命令形で、具体的な件名にする
• 末尾にピリオドを付けない
• ユーザーから明示的に求められない限り、Co-authored-by のトレーラーを付けない
• コミットで確認済みの GitHub Issue を修正する場合は、件名の末尾に #<number> を付ける

件名を確定する前に、次の点を確認してください。

• 関数、API、型、ユーザーから見た効果など、差分に現れる用語を使って、具体的な動作と対象を示します。
• 包括的な表現を新たに作るよりも、影響を受けるシンボルや型を明記します。件名は git log で検索できるものにしてください。
• 複数の無関係な差分に当てはまりそうな件名は避けます。「差分を開かなくても、何が変わったか分かるか」と考えてください。
• 具体的な変更内容を示せる場合は、動作を改善する、処理を更新する、コレクションの値を比較する のような曖昧な抽象表現を避けます。

Issue 番号のサフィックスを付けるのは、そのコミットが Issue の修正を目的としている場合に限ります。単に関連している場合や、調査中に見つかった場合には付けません。明示的に修正した複数の Issue がある場合は、確認済みの参照をそれぞれ末尾に付けます。リポジトリ固有のメッセージ規則やユーザーからの明示的な指示がある場合は、そちらを優先してください。

例：

fix: preserve scroll offset after prepend
fix: preserve failed CRUD creates #547

スコープ付きの件名（fix(list): ...）や、曖昧な要約（update stuff）は避けてください。

タイトルだけでは分からない動作変更の理由、不変条件、検証内容がある場合は、本文に記載してください。

計画の出力

計画モードが有効な場合は、次のように提示してください。

Proposed commits (N):
1. type: concrete subject
   Rationale: Why this group belongs together.
   Files: path/a, path/b

続けて go または修正内容を入力するよう求めてください。ユーザーの承認を得るまで、ステージングやコミットを行わないでください。

直接実行モードでは、この計画を内部で立ててください。複数のコミットに分ける場合にユーザーが進捗を把握しやすくなるときに限り、コミット前またはコミット中に簡潔な要約を示してください。

コミット

各グループについて、次の手順を実行してください。

1. パスまたはハンクを限定して、そのグループだけをステージングします。対象外の変更を黙ってステージングから外してはいけません。
2. git diff --staged --stat、対象を絞った git diff --staged、git diff --staged --check を使って、予定したコミットにそのグループだけが含まれていることを確認します。無関係なインデックス項目が残っている場合は、所有範囲が明確なパスだけに限定してコミットし、そのパスを個別に確認します。
3. 合意済みのメッセージでコミットします。
4. フックの実行後に作業ツリーを再確認してから、次のグループに進みます。コミット前フックがリポジトリで文書化された範囲付きチェックより広いチェックを実行する場合は、リポジトリで文書化された方法で範囲を限定するか、フックをスキップし、そのことを伝えてください。

すべてのコミットが完了したら、コミットハッシュと、未ステージングのファイルが残っているかどうかを報告してください。コミットに失敗した場合は、そこで停止し、正確な失敗内容と現在の Git の状態を報告してください。