git-commit
gitコミットを作成する。ブランチ確認・ステージング・メッセージ生成を一括で行う。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
gitコミットを作成する。ブランチ確認・ステージング・メッセージ生成を一括で行う。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
| name | git-commit |
| description | gitコミットを作成する。ブランチ確認・ステージング・メッセージ生成を一括で行う。 |
以下のコマンドを並列で実行:
git status(未追跡ファイル確認。-uallは使わない)git diff --staged(ステージ済みの変更内容)git diff(未ステージの変更内容)git log --no-merges --oneline -20(prefixスタイル・言語参照用。マージコミットはprefixが付かずカウントを歪めるため除外)git branch --show-current(現在のブランチ名)git log --oneline -20(マージコミット含む)の1行目を確認する。以下のいずれかが複数あればGitHubのPull Request運用とみなす:
... (#1)、squashマージ)Merge pull request #1 ... で始まる(マージコミット)どちらも無ければ、mainへ直接コミットする運用(dotfiles等)とみなす。
今回の変更がそのブランチの作業に属するか判定する。
git log --oneline <base>..HEAD(<base> は main か master)でブランチ固有のコミットを確認する誤検知しうるため、少しでも関連しそうなら「そのまま続行」に倒す。
新規ブランチを切る場合のベースは現ブランチ(git switch -c で作成すれば、未コミットの変更はそのまま新ブランチに引き継がれる。stashは不要)。
ブランチ名のルール:
/ は使わない。- で区切る(例: fix-typo-in-readme, feat-add-login-page)ステージ済みファイルがない場合:
.env、認証情報等のファイルが含まれる場合は警告するステージ済みファイルがある場合はそのまま続行。
変更理由が不明な場合はユーザーに質問する。
本文は why が伝わる最短の表現にする。1文で足りるなら1文で終える。 根拠を添える場合も要点だけにし、説明を重ねない。
変更内容(what)は git diff で確認できるが、変更理由(why)はコミットメッセージにしか記録できない。diffから読み取れる情報の優先度は低い。会話の文脈から以下を読み取りメッセージの主軸にする:
typo修正などの自明な変更を除き、必ず変更が必要だった理由を記載する。
「不要」「不適切」「古い」「冗長」などの主観的な判断を含むコミットメッセージは、将来の開発者がその妥当性を検証できない。なぜそう判断したのかの根拠を必ず記載する。
❌ 悪い例:
不要なコードを削除
✅ 良い例:
未使用のUserSerializer classを削除
grepで検索した結果、プロジェクト内に呼び出し元が存在しない。
2024年のAPI v2移行時に旧エンドポイントと共に不要になったもの。
有効な根拠の例: 検索結果(呼び出し元0件)、意思決定の経緯、技術的事実、エラー/不具合の証拠、数値データ。
本文の各文を書く前に「この情報は diff を読めばわかるか?」を判断する:
変更内容が1行のサマリーで完全に理解でき、「なぜ」が自明な場合のみ省略可:
「不要コード削除」は本文省略不可。なぜ不要と判断したかの根拠が必要。
ステップ1の git log(マージ除外済み)を確認し判定する:
feat:, fix:, chore:, refactor:, perf:, style:, test:, docs:, ci:, build: など)を使う場合のみ prefix を使うprefix を使う場合の型:
feat: リリースノートに「新機能」として書けるかfix: ユーザー/システムが困る不具合の修正かchore: それ以外の裏方作業refactor/perf/style/test/docs/ci/build: 当てはまればそれを優先!(例: feat!: APIレスポンスの形式を変更)過去のコミットログはprefixスタイルの参照のみに使う。過去のコミットメッセージの品質が高い保証はないため、メッセージの内容・詳細度・書き方を過去に合わせてはならない。常にこのスキルのルールに従って高品質なメッセージを生成する。
git log --oneline -20 で直近のコミットメッセージを確認
`)で囲む(例: USE_IAM_PROFILE、aws_access_key_id)。GitHubのコミット詳細画面でMarkdownとしてレンダリングされ、可読性が向上するユーザーに見せる前にメッセージを一度読み返し、ステップ4のルールを再適用する。 特に本文の各行を diff と突き合わせ、自明な行は削除する。冗長さは生成直後より 読み返したときに気づきやすい。
以下の内容をまとめて1回だけ確認する:
ユーザーの承認後、以下を順次実行:
git switch -c {ブランチ名}git add で個別にステージgit commit -m "$(cat <<'EOF'
コミットメッセージ1行目
本文(必要な場合)
EOF
)"
pre-commit hookが失敗した場合:
--amend は絶対に使わない。hookが失敗した場合コミットは作成されていないため、--amendは前のコミットを書き換えてしまう)git push はこのスキル内では実行しない(ユーザーが明示的に依頼した場合のみ)--amend は使わない--no-verify は使わない.env、認証情報、シークレットファイルのコミットは警告する