git-commit

name	git-commit
description	ワーキングディレクトリの変更をConventional Commitsに従ってコミットするスキル。 意味のある変更単位ごとにステージングし、英語でコミットメッセージを作成する。 co-authorやエージェント名をコミットメッセージに含めない。 ユーザーが「コミットして」「変更をコミット」「git commit」「commitして」 「この変更をコミット」「コミットメッセージを書いて」「コミットお願い」 などコミット関連のリクエストをした場合に必ず使用すること。 pushは含まない（コミットのみ）。

Git Commit

意味のある変更単位ごとにコミットを行うことで、コードの履歴を明確にし、将来の変更追跡を容易にする。

手順

1. 直近のコミット履歴を確認する

プロジェクトのコミットスタイルを把握するため、直近の履歴を確認する。

git log --oneline -10

2. 変更内容を確認する

ワーキングディレクトリの状態を確認する。-uallフラグは大規模リポジトリでメモリ問題を起こす可能性があるため使わないこと。

git status
git diff
git diff --staged

3. 意味のある単位でステージングする

変更を意味のある単位ごとにステージングする。git add -A や git add . で無条件に全ファイルを追加してはならない。対象ファイルを個別に指定すること。

git add <対象ファイルやディレクトリ>

以下のファイルはコミットに含めないこと：

• .env やクレデンシャル情報を含むファイル
• ユーザーが明示的に除外を指示したファイル

一つのコミットに含める変更が論理的に独立した複数の変更を含む場合は、複数のコミットに分割することを検討する。

4. コミットメッセージを作成してコミットする

Conventional Commitsの形式に従い、英語でコミットメッセージを作成する。

git commit -m "$(cat <<'EOF'
<type>(<scope>): <description>

<body（必要な場合）>
EOF
)"

コミットメッセージのルール:

• Conventional Commits形式: type(scope): description
  • type: feat, fix, docs, style, refactor, test, chore, ci, perf, build など
  • scope: 変更の影響範囲（省略可）
  • description: 変更内容の簡潔な説明
• 英語で記述する
• co-authorやエージェント名（"Claude Code"など）をコミットメッセージに含めない
• 変更の「何を」ではなく「なぜ」を重視する
• descriptionは命令形（imperative mood）で書く（例: "add" not "added"）

5. コミットを確認する

コミットが正しく行われたかを確認する。

git log --oneline -5

注意事項

• pre-commitフックが失敗した場合、コミットは作成されていない。問題を修正して新しいコミットを作成すること（--amendは使わない）
• --no-verifyでフックをスキップしない。フックが失敗したら原因を調査して修正する
• pushはこのスキルの範囲外。ユーザーから明示的に指示がない限りpushしない