commit

name	commit
description	セッション履歴を根拠およびサマリとして使用し、現在の変更からきちんとした git コミットを作成する。コミット作成、コミットメッセージの準備、または staged な作業のファイナライズを依頼されたときに使用する。

Commit

ゴール

• 実際のコード変更とセッションコンテキストを反映するコミットを作成する。
• 一般的な git の慣習に従う（type プレフィックス、短い subject、ラップされた body）。
• body にサマリと根拠の両方を含める。

入力

• 意図と根拠のための Codex セッション履歴。
• 実際の変更を確認する git status、git diff、git diff --staged。
• 文書化されている場合はリポジトリ固有のコミット規約。

手順

1. セッション履歴を読み、スコープ、意図、根拠を特定する。
2. 作業ツリーと staged な変更を検査する（git status、git diff、git diff --staged）。
3. スコープを確認した後、新しいファイルも含めて意図した変更をステージする（git add -A）。
4. 新しく追加されたファイルをサニティチェックする。何かがランダムに見えたり ignored されている可能性が高い場合（ビルド成果物、ログ、一時ファイル）、コミット前にユーザーにフラグを立てる。
5. ステージングが不完全か、無関係なファイルを含む場合は、index を修正するか確認を求める。
6. 変更に合致した慣習的な type と任意の scope を選ぶ（例: feat(scope): ...、fix(scope): ...、refactor(scope): ...）。
7. 命令法・72 文字以下・末尾ピリオドなしで subject 行を書く。
8. 以下を含む body を書く:
   • 主要な変更のサマリ（何が変わったか）。
   • 根拠とトレードオフ（なぜ変えたか）。
   • 実行されたテストや検証（または実行していない場合の明示的なノート）。
9. ユーザーが明示的に別の identity を要求しない限り、Codex 用の Co-authored-by トレーラを Codex <[e-mail]> で付与する。
10. body 行を 72 文字でラップする。
11. heredoc または一時ファイルでコミットメッセージを作成し、git commit -F <file> を使って改行をリテラルにする（-m での \n は避ける）。
12. メッセージが staged な変更と合致するときのみコミットする: staged な diff に無関係なファイルが含まれているか、メッセージが staged されていない作業を記述している場合は、コミット前に index を修正するかメッセージを修正する。

出力

• そのセッションを反映したメッセージを持つ単一のコミットが git commit で作成される。

テンプレート

type と scope はあくまで例。リポジトリと変更に合わせて調整する。

<type>(<scope>): <短いサマリ>

Summary:
- <何が変わったか>
- <何が変わったか>

Rationale:
- <なぜ>
- <なぜ>

Tests:
- <コマンド または "実行していない（理由）">

Co-authored-by: Codex <[e-mail]>