commit

name	commit
description	現在の変更内容とセッション履歴をもとに、根拠のある整った `git commit`を作成する。コミット作成、コミットメッセージ準備、またはステージ済み作業の仕上げを頼まれたときに使う。

Commit

目的

• 実際のコード変更とセッション文脈を反映したコミットを作る。
• 一般的な Git の慣習（type 接頭辞、短い件名、折り返した本文）に従う。
• 本文に変更内容の要約と背景の両方を含める。

入力

• 意図と背景を把握するための Codex セッション履歴。
• 実際の差分を確認するための git status、git diff、git diff --staged。
• 文書化されていれば、このリポジトリ固有のコミット規約。

手順

1. セッション履歴を読み、対象範囲・意図・背景を把握する。
2. ワーキングツリーとステージ済み差分を確認する（git status、git diff、git diff --staged）。
3. 対象範囲を確認したうえで、新規ファイルを含む意図した変更をステージする（git add -A）。
4. 新しく追加されたファイルを軽く点検する。ランダムなファイルや本来無視されるはずのもの（ビルド成果物、ログ、一時ファイルなど）が混ざっていそうなら、コミット前にユーザーへ知らせる。
5. ステージが不完全、または無関係なファイルを含む場合は、インデックスを修正するか確認を取る。
6. 変更内容に合う一般的な type と必要なら scope を選ぶ（例: feat(scope): ...、fix(scope): ...、refactor(scope): ...）。
7. 件名は命令形で、72 文字以内、末尾のピリオドなしで書く。
8. 本文には以下を含める。
   • 主要な変更点の要約（何を変えたか）
   • 背景とトレードオフ（なぜ変えたか）
   • 実行したテストや検証（未実施ならその旨を明記）
9. ユーザーから別の指定がない限り、Codex 用の Co-authored-by: Codex <[e-mail]> を末尾に付ける。
10. 本文の各行は 72 文字で折り返す。
11. コミットメッセージは here-doc か一時ファイルで作り、git commit -F <file> を使って改行をそのまま渡す（\n 付き -m は使わない）。
12. メッセージがステージ内容と一致するときだけコミットする。ステージ差分に無関係なファイルがある、またはメッセージが未ステージの作業を説明している場合は、コミット前にインデックスかメッセージを修正する。

出力

• セッション内容を反映したメッセージで git commit により作成された1 つのコミット。

テンプレート

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

<type>(<scope>): <short summary>

Summary:
- <what changed>
- <what changed>

Rationale:
- <why>
- <why>

Tests:
- <command or "not run (reason)">

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