Menu
gitコミットを作成する。ブランチ確認・ステージング・メッセージ生成を一括で行う。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
| 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、認証情報、シークレットファイルのコミットは警告する