git-commit

name	git-commit
description	gitコミットを作成する。ブランチ確認・ステージング・メッセージ生成を一括で行う。

git-commit スキル

手順

ステップ1: 現状把握

以下のコマンドを並列で実行:

• git status（未追跡ファイル確認。-uallは使わない）
• git diff --staged（ステージ済みの変更内容）
• git diff（未ステージの変更内容）
• git log --no-merges --oneline -20（prefixスタイル・言語参照用。マージコミットはprefixが付かずカウントを歪めるため除外）
• git branch --show-current（現在のブランチ名）

ステップ2: ブランチ判定

前提: リポジトリがPR運用か判定

git log --oneline -20（マージコミット含む）の1行目を確認する。以下のいずれかが複数あればGitHubのPull Request運用とみなす:

• 末尾にPR番号がある（例: ... (#1)、squashマージ）
• Merge pull request #1 ... で始まる（マージコミット）

どちらも無ければ、mainへ直接コミットする運用（dotfiles等）とみなす。

main/masterブランチの場合

• PR運用 → 新規ブランチ作成が必要
• 直接コミット運用 → そのままコミットしてよい

それ以外のブランチの場合

今回の変更がそのブランチの作業に属するか判定する。

1. git log --oneline <base>..HEAD（<base> は main か master）でブランチ固有のコミットを確認する
2. 判定:
   • コミットが無い（作業用に切っただけ）→ そのまま続行
   • 既存コミットのテーマや会話の文脈と関連する → そのまま続行
   • 明確に無関係（別タスクの変更が紛れ込んでいる）→ ステップ5で新規ブランチ作成を「推奨」として提案し、最終判断はユーザーに委ねる

誤検知しうるため、少しでも関連しそうなら「そのまま続行」に倒す。

新規ブランチを切る場合のベースは現ブランチ（git switch -c で作成すれば、未コミットの変更はそのまま新ブランチに引き継がれる。stashは不要）。

ブランチ名のルール:

• / は使わない。- で区切る（例: fix-typo-in-readme, feat-add-login-page）

ステップ3: ステージング判定

ステージ済みファイルがない場合:

• 会話の文脈や実装状況から、ステージすべきファイルを判断する
• .env、認証情報等のファイルが含まれる場合は警告する

ステージ済みファイルがある場合はそのまま続行。

ステップ4: コミットメッセージ生成

変更理由が不明な場合はユーザーに質問する。

基本原則: 簡潔さを優先する

本文は why が伝わる最短の表現にする。1文で足りるなら1文で終える。 根拠を添える場合も要点だけにし、説明を重ねない。

基本原則: 「なぜ」を記載する

変更内容（what）は git diff で確認できるが、変更理由（why）はコミットメッセージにしか記録できない。diffから読み取れる情報の優先度は低い。会話の文脈から以下を読み取りメッセージの主軸にする:

• 何が問題だったのか（背景・課題）
• このコミットでどう改善されるのか（効果・目的）

typo修正などの自明な変更を除き、必ず変更が必要だった理由を記載する。

主観的な判断には客観的根拠を添える

「不要」「不適切」「古い」「冗長」などの主観的な判断を含むコミットメッセージは、将来の開発者がその妥当性を検証できない。なぜそう判断したのかの根拠を必ず記載する。

❌ 悪い例:

不要なコードを削除

✅ 良い例:

未使用のUserSerializer classを削除

grepで検索した結果、プロジェクト内に呼び出し元が存在しない。
2024年のAPI v2移行時に旧エンドポイントと共に不要になったもの。

有効な根拠の例: 検索結果（呼び出し元0件）、意思決定の経緯、技術的事実、エラー/不具合の証拠、数値データ。

コミットメッセージの構造

• 1行目: 変更内容の簡潔な要約。50文字以内推奨（最大72文字）、命令形（「〜を追加」「〜を修正」「〜を削除」）、末尾に句読点なし。prefix は任意（下記判定に従う）
• 2行目: 空行
• 3行目以降: 動機・背景（なぜ必要だったか）を簡潔に。自明な変更を除き必須。72文字程度で改行。関連するissue/PR番号があれば含める

本文の取捨選択ルール

本文の各文を書く前に「この情報は diff を読めばわかるか？」を判断する:

• diff から自明 → 書かない: 具体的なコード変更の説明（何を追加した、どのオプションを指定した等）
• diff からは読み取れない → 書く: 変更が必要になった動機・背景・課題
• diff が複雑で全体像が掴みにくい → 書いてよい: 変更の概要（ただし簡潔に）

本文が省略できる場合

変更内容が1行のサマリーで完全に理解でき、「なぜ」が自明な場合のみ省略可:

• typo修正
• lint/フォーマット修正

「不要コード削除」は本文省略不可。なぜ不要と判断したかの根拠が必要。

Conventional Commits prefix

ステップ1の git log（マージ除外済み）を確認し判定する:

• 直近20件の**過半数（11件以上）**が prefix（feat:, fix:, chore:, refactor:, perf:, style:, test:, docs:, ci:, build: など）を使う場合のみ prefix を使う
• それ未満なら付けてはならない（「任意」ではなく禁止）。学習傾向で付けがちだが、既存スタイルに合わない prefix は履歴の一貫性を損なう

prefix を使う場合の型:

• feat: リリースノートに「新機能」として書けるか
• fix: ユーザー/システムが困る不具合の修正か
• chore: それ以外の裏方作業
• refactor/perf/style/test/docs/ci/build: 当てはまればそれを優先
• 破壊的変更は型の後に !（例: feat!: APIレスポンスの形式を変更）

過去のコミットログの参照について

過去のコミットログはprefixスタイルの参照のみに使う。過去のコミットメッセージの品質が高い保証はないため、メッセージの内容・詳細度・書き方を過去に合わせてはならない。常にこのスキルのルールに従って高品質なメッセージを生成する。

その他のルール

• コミットメッセージの言語: リポジトリの既存コミットログに合わせる
  • 判定方法: git log --oneline -20 で直近のコミットメッセージを確認
    • 大半が日本語 → 日本語で記述（技術用語は英語のまま使ってよい）
    • 大半が英語 → 英語で記述
    • 混在・初回コミット等で判定不能の場合 → README やソースコード内のコメント言語から推測。それでも不明なら英語をデフォルトとする
  • ユーザーから明示的な指示があればそれを優先する
• 技術用語の表記: 公式表記を遵守する（GitHub, RuboCop, TypeScript, Next.js, PostgreSQL, nginx 等）
• 変数名・関数名・コマンド名などのコード要素: バッククォート（`）で囲む（例: USE_IAM_PROFILE、aws_access_key_id）。GitHubのコミット詳細画面でMarkdownとしてレンダリングされ、可読性が向上する
• コミット粒度: 独立してリバートできるアトミックな単位。変更理由ごとにコミットを分ける。ステージ済みの変更が複数の論理的変更を含む場合、コミットの分割を提案する

ステップ4.5: 提示前の読み返し

ユーザーに見せる前にメッセージを一度読み返し、ステップ4のルールを再適用する。 特に本文の各行を diff と突き合わせ、自明な行は削除する。冗長さは生成直後より 読み返したときに気づきやすい。

ステップ5: ユーザー確認（1回のみ）

以下の内容をまとめて1回だけ確認する:

• ブランチ: 新規作成する場合はブランチ名。非mainで別ブランチを推奨する場合はなぜ無関係と判断したか理由を添える（ユーザーが断れば現ブランチにそのままコミットする）。既存ブランチにそのまま続行する場合はそのブランチ名
• ステージ対象: ステージするファイル一覧（既にステージ済みの場合はその旨）
• コミットメッセージ: 生成したメッセージ全文

ユーザーの承認後、以下を順次実行:

1. ブランチ作成（必要な場合）: git switch -c {ブランチ名}
2. ファイルのステージ（必要な場合）: git add で個別にステージ
3. コミット実行（HEREDOC形式）:

git commit -m "$(cat <<'EOF'
コミットメッセージ1行目

本文（必要な場合）
EOF
)"

ステップ6: hook失敗時の対応

pre-commit hookが失敗した場合:

1. エラー内容を分析
2. 問題を修正
3. 修正ファイルを再ステージ
4. 新規コミットを作成（--amend は絶対に使わない。hookが失敗した場合コミットは作成されていないため、--amendは前のコミットを書き換えてしまう）

禁止事項

• git push はこのスキル内では実行しない（ユーザーが明示的に依頼した場合のみ）
• --amend は使わない
• --no-verify は使わない
• .env、認証情報、シークレットファイルのコミットは警告する