--- 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 ` で付与する。 10. body 行を 72 文字でラップする。 11. heredoc または一時ファイルでコミットメッセージを作成し、`git commit -F ` を使って改行をリテラルにする（`-m` での `\n` は避ける）。 12. メッセージが staged な変更と合致するときのみコミットする: staged な diff に無関係なファイルが含まれているか、メッセージが staged されていない作業を記述している場合は、コミット前に index を修正するかメッセージを修正する。 ## 出力 - そのセッションを反映したメッセージを持つ単一のコミットが `git commit` で作成される。 ## テンプレート type と scope はあくまで例。リポジトリと変更に合わせて調整する。 ``` (): <短いサマリ> Summary: - <何が変わったか> - <何が変わったか> Rationale: - <なぜ> - <なぜ> Tests: - <コマンド または "実行していない（理由）"> Co-authored-by: Codex ```