git-commit

Git コミット

現在の作業ツリーの変更から、質の高い単一の Git コミットを作成します。

コンテキスト

Claude Code を使用していない場合は、以下の「コンテキストのフォールバック」に進み、そこに記載されたコマンドを実行してコンテキストを収集してください。

Claude Code を使用している場合は、以下の5つのラベル付きセクション（Git ステータス、作業ツリーの差分、現在のブランチ、最近のコミット、リモートのデフォルトブランチ）に、あらかじめデータが入力されています。このスキル全体を通してそれらを直接使用してください。これらのコマンドを再実行しないでください。

Git ステータス： !git status

作業ツリーの差分： !git diff HEAD

現在のブランチ： !git branch --show-current

最近のコミット： !git log --oneline -10

リモートのデフォルトブランチ： !git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo '__DEFAULT_BRANCH_UNRESOLVED__'

コンテキストのフォールバック

Claude Code を使用している場合は、このセクションをスキップしてください。上記ですでにデータを取得しています。

以下の単一のコマンドを実行して、すべてのコンテキストを収集してください。

printf '=== STATUS ===\n'; git status; printf '\n=== DIFF ===\n'; git diff HEAD; printf '\n=== BRANCH ===\n'; git branch --show-current; printf '\n=== LOG ===\n'; git log --oneline -10; printf '\n=== DEFAULT_BRANCH ===\n'; git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo '__DEFAULT_BRANCH_UNRESOLVED__'

---

ワークフロー

ステップ 1：コンテキストを収集する

上記のコンテキスト（Git ステータス、作業ツリーの差分、現在のブランチ、最近のコミット、リモートのデフォルトブランチ）を使用してください。このステップに必要なデータはすべてすでに利用可能です。これらのコマンドを再実行しないでください。

リモートのデフォルトブランチの値は、origin/main のような形式で返されます。origin/ プレフィックスを取り除いて、ブランチ名を取得してください。値が __DEFAULT_BRANCH_UNRESOLVED__ または単独の HEAD の場合は、次を試してください。

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

どちらも失敗した場合は、main を使用してください。

上記のコンテキストにある Git ステータスが作業ツリーに変更がないこと（ステージ済み、変更済み、未追跡のファイルがないこと）を示している場合は、コミットするものがないことを伝え、終了してください。

上記のコンテキストで現在のブランチが空の場合、リポジトリは detached HEAD 状態です。ユーザーがこの作業をブランチに紐付けたい場合は、コミット前にブランチが必要であることを説明してください。ここでフィーチャーブランチを作成するかどうかを尋ねてください。プラットフォームのブロッキング質問ツール（Claude Code では AskUserQuestion、Codex では request_user_input、Gemini では ask_user）を使用してください。質問ツールが利用できない場合は選択肢を提示し、ユーザーの返信を待ってから続行してください。

• ユーザーがブランチの作成を選んだ場合は、変更内容からブランチ名を決め、git checkout -b <branch-name> で作成します。その後、git branch --show-current を再度実行し、以降のワークフローではその結果を現在のブランチ名として使用してください。
• ユーザーが作成しないことを選んだ場合は、detached HEAD のままコミットを続行してください。

ステップ 2：コミットメッセージの規約を判断する

次の優先順位に従ってください。

1. コンテキスト内のリポジトリ規約 -- プロジェクトの指示（AGENTS.md、CLAUDE.md など）がすでに読み込まれており、コミットメッセージの規約が指定されている場合は、それに従ってください。これらのファイルを再読込しないでください。セッション開始時に読み込まれています。
2. 最近のコミット履歴 -- 明示的な規約が記載されていない場合は、ステップ 1 で確認した直近10件のコミットを調べてください。明確なパターン（Conventional Commits、チケット番号のプレフィックス、絵文字のプレフィックスなど）があれば、そのパターンに合わせてください。
3. デフォルト：Conventional Commits -- どちらからもパターンが見つからない場合は、Conventional Commits 形式の type(scope): description を使用してください。type には feat、fix、docs、refactor、test、chore、perf、ci、style、build のいずれかを指定します。

ステップ 3：論理的なコミットを検討する

すべてを一緒にステージする前に、変更されたファイルを確認し、自然に区別できる内容がないかを調べてください。変更されたファイルが明確に別々の論理的な変更に分かれている場合（例：あるディレクトリのリファクタリングと別のディレクトリの新機能、またはソースファイルとは別の変更に関するテストファイル）は、それぞれ別のコミットを作成してください。

簡潔に行ってください。

• グループ分けはファイル単位のみで行います。git add -p を使用したり、ファイル内のハンクを分割したりしないでください。
• 分割が明確な場合（別々の機能や無関係な修正）は分けてください。判断が難しい場合は、1つのコミットで問題ありません。
• 2〜3個の論理的なコミットが適切です。細かいコミットを多数作るために過度に分割しないでください。

ステップ 4：ステージングとコミット

上記のコンテキストにある現在のブランチが main、master、またはステップ 1 で解決したデフォルトブランチの場合は、ユーザーに警告し、このブランチでコミットを続けるか、先にフィーチャーブランチを作成するかを尋ねます。プラットフォームのブロッキング質問ツール（Claude Code では AskUserQuestion、Codex では request_user_input、Gemini では ask_user）を使用します。質問ツールが利用できない場合は、選択肢を提示し、ユーザーの返信を待ってから続行します。ユーザーがブランチの作成を選んだ場合は、変更内容に基づいて名前を決め、git checkout -b <branch-name> で作成してから続行します。

コミットメッセージを作成します。

• 件名行：簡潔な命令形とし、何をではなくなぜに焦点を当てます。ステップ 2 で判定した規約に従います。
• 本文（必要な場合）：重要な変更では、空行を挟んで本文を追加します。動機、トレードオフ、または将来の読者に必要な情報を説明します。明らかに単一の目的を持つ変更では、本文を省略します。

コミットグループごとに、ステージングとコミットを 1 回の呼び出しで行います。機密ファイル（.env、認証情報）や無関係な変更を誤って含めないよう、git add -A や git add . よりも、ファイル名を指定してステージングする方法を優先します。書式を保つためにヒアドキュメントを使用します。

git add file1 file2 file3 && git commit -m "$(cat <<'EOF'
type(scope): subject line here

Optional body explaining why this change was made,
not just what changed.
EOF
)"

ステップ 5：確認

コミット後に git status を実行し、成功を確認します。コミットハッシュと件名行を報告します。