commit
Git変更をコミットしてリモートにプッシュ。「コミット」「コミットして」「pushして」「変更を保存して」と言われた時、またはバグ修正・新機能・リファクタリング完了後に使用
Commit Workflow
このスキルは現在の変更をGitブランチにコミットします。
実行手順
1. ブランチ確認
ブランチ構成は .claude/skills/_shared/branch-strategy.md を参照。現在のブランチと利用可能なブランチを確認する:
git branch --show-current
git branch -a
- 作業ブランチにいる場合: そのまま進む
- 保護ブランチ（main/staging等）にいる場合:
create-branchスキルでブランチ作成後に進む - ブランチ戦略が存在しない場合: ブランチ作成の要否をユーザーに確認
2. 変更内容の確認
git status
git diff
3. コミットメッセージの作成
変更をステージングし、差分を確認する:
git add <files>
git diff --cached
以下のルールに従ってコミットメッセージを作成する。
タイトルのルール
- why中心: 「何を変えたか」ではなく「なぜ変えたか」を書く。diffを見れば"what"はわかる。タイトルから「この変更の動機・目的」が読み取れること
- 体言止め: 末尾は動名詞（
〜を追加/〜を修正/〜に対応/〜を改善）で終える - 50文字程度: 日本語で50文字以内を目安
- 英日間スペース禁止:
N+1クエリやUserモデルのように詰める - レビュープロセスに言及しない: 「レビュー指摘の修正」「フィードバックを受けて」等は禁止。変更の動機を直接書く（
~/dotfiles/.claude/rules/communication.mdの"No review-process meta"ルール参照）
本文の改行ルール（最重要）
本文の散文部分は必ず1段落・1行で書き切る。どれだけ長くなっても途中で改行しない。
改行してよいのは箇条書き（- で始まる行）の間のみ。
NG（途中改行あり）:
検索結果の表示時に関連レコードを
個別取得していたため、
eager loadingを導入して一括取得に変更。
OK（1行で書き切る）:
検索結果の表示時に関連レコードを個別取得していたため、eager loadingを導入して一括取得に変更。
理由: Gitの各種ツール（git log --oneline、GitHub/GitLab UI）は段落を改行で区切る。散文の途中で改行すると、表示上は別の段落として扱われ意図が壊れる。
パターン選択
情報量の多い順（A -> B -> C）に検討し、最初に該当するパターンを採用する:
パターンA: タイトル + 本文 + 箇条書き — 複数の関連変更を含み、本文に収まらない要点の列挙がある場合
タイトル（why中心）
背景・目的を1段落・1行で書く（ここで改行しない）
- 具体的な変更1
- 具体的な変更2
本文と箇条書きはどちらか一方を省略してもよい。
パターンB: タイトル + 本文 — 上記以外すべての既定。背景説明が必要な変更
タイトル（why中心）
背景・目的・経緯を1段落・1行で書く（ここで改行しない）
本文は「1文目: 何が問題だったか・なぜ現状のままでは駄目か、2文目: どう対処するか」の2文を基本に、平易な日本語でまとめる。変更内容を繰り返すだけの1文の本文は書かない — 1文で済むほど小さい変更ならパターンCにする。クラス名・定数名・メソッド名などのコード要素の列挙は避ける — 変更内容の列挙はdiffの繰り返しになり、メッセージが冗長になるだけ。
パターンC: タイトルのみ — 1ファイル・数行の小さな変更（タイポ修正、設定の微調整等）で、タイトルだけで動機を説明し切れる場合
タイトル（why中心、50文字程度）
3.5 日本語セルフチェック（必須ゲート）
この照合表を出力せずに git commit を実行してはならない。 コミットメッセージは-mで渡すためファイル書き込みのチェックを通らず、機械的な検出が効かない。ここで人手の照合を必ず行い、その結果をテキストで出力すること。「確認した」という宣言だけでは完了と見なさない。
作成したコミットメッセージのタイトルと本文を1行ずつ声に出して読み、以下の観点で照合する:
- 漢語接頭辞の造語（未〜/非〜で名詞と合成した語。例: 未充足、非終端）
- 助詞の省略（例: 「次エッジ」->「次のエッジ」、「LIKE検索」->「LIKEで検索」）
- 既存の語彙にない業務用語の造語（例: 「付随記録」「表示前提」）
- 禁止語の「契約」「述語」 -> 具体的なインターフェース、条件、挙動、要件に言い換える（「API契約」やプロジェクトで確立済みの用語も例外にしない）
出力形式（必須）: 次の表を必ず出力する。指摘がない場合も「指摘なし」と1行明記する。
| 対象行 | 元の表現 | 判定 | 修正後 |
|---|---|---|---|
| タイトル | （原文） | OK / 造語 / 助詞省略 / 禁止語 | （修正案。OKなら空欄） |
| 本文1行目 | （原文） | ... | ... |
プロジェクトで確立済みのドメイン用語は造語として扱わない。不自然な表現があれば修正し、修正後のメッセージでコミットする。
禁止事項: 照合表を出力せずに「セルフチェック済み」とだけ述べてコミットに進むこと。表の出力がこのステップを完了した唯一の証拠となる。
4. ユーザー確認
git commitコマンド形式でユーザーに提示し、許可を得る。
# パターンC
git commit -m "タイトル"
# パターンA / B（HEREDOC使用）
git commit -m "$(cat <<'EOF'
タイトル
本文（1行）
- 箇条書き
EOF
)"
変更ファイル:
- ファイル一覧
ユーザーの許可なしにコミットを実行しない。
5. コミット実行と後処理
ユーザーの許可後にコミットを実行する。
~/.claude/plans/*.mdが存在する場合、完了したTODO項目を- [x]に更新する。
Troubleshooting
| エラー | 原因 | 対処 |
|---|---|---|
| pre-commitフックがコミットを拒否する | lintエラー・secretが含まれている等 | エラーメッセージを確認して修正後に再コミット（--no-verifyは使わない） |
使用例
詳細な使用例は references/usage-examples.md を参照してください。
次のステップ
プルリクエストを作成する場合は、prスキルを使用してください。