---
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 <codex@openai.com>` で付与する。
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 <codex@openai.com>
```