| name | committing |
| description | Conventional Commits形式でgitコミットを作成する。「コミット」「commit」「変更をコミット」「コミットして」「コミットお願い」「この変更を保存」「git commit」「変更を記録」と言及された時に使用。hunk単位でステージングしコミットメッセージを自動生成する。プッシュやPR作成は対象外。 |
| context | fork |
| agent | general-purpose |
| allowed-tools | Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git restore:*), Bash(git log:*) |
コミット作成
ワークフロー
- ブランチ確認:
git branch --show-current で現在のブランチを確認
- main または master の場合: 先に
git checkout -b feature/<内容に応じた名前> でブランチを作成してから作業を進める
- 既に feature ブランチの場合: そのまま続行
git diff で変更内容を確認- 各 hunk（変更ブロック）を分析し、それぞれの「動作・振る舞い」を特定
- 動作ごとにグループ化（「〜する」で説明できる単位）
- 各グループに Conventional Commits タイプを決定
git add -p で hunk 単位でステージし、グループごとにコミット- 全グループをコミットし終えたらサマリーを表示
分割の判断基準
必ず分けるケース
- 異なる「動作」は別コミット
- 「読み込む」と「保存する」は別
- 「追加する」と「削除する」は別
- 「表示する」と「非表示にする」は別
- コミットメッセージの body に複数の箇条書きを書きたくなったら分割のサイン
- Conventional Commits タイプが異なる場合
同じコミットにまとめてよいケース
- 1つの動作を実現するために必要な複数の変更（import文とその使用箇所など）
- 同じ目的の同じ種類の変更（複数ファイルの同じリファクタリングなど）
git add -p の使い方
git add -p <file>
git commit -m "type: description"
git add -p <file>
git commit -m "type: description"
ルール
- Conventional Commits 形式:
type: description
- 1コミット = 1動作（「〜する」で表現できる1つの振る舞い）
- description だけで変更内容が伝わるようにする（body は補足のみ）
- 迷ったら分割（後から squash は簡単、分割は難しい）
Worktree 対応
- git worktree 内で起動された場合、全ての git 操作はその worktree 内で実行すること
- 親リポジトリ（
.worktree/ の親ディレクトリ）でコミットを作成してはいけない
git rev-parse --show-toplevel で現在の worktree ルートを確認し、そのディレクトリ内で操作する
確認なしで分析とコミットを進めること。
