git-commit について
git-commitは、Gitのコミットメッセージ作成ルールを定めるリポジトリ向けスキルです。件名と本文の形式、表現、内容に加え、推奨するHEREDOCコマンド形式を示します。
主な機能
- 017項目のコミットメッセージ規則
- 02件名と本文の書式ガイド
- 03変更内容を簡潔に伝える指針
- 04HEREDOCコマンドのテンプレート
- 05良い例と悪い例
活用シーン
- 01リポジトリ内のコミット形式の統一
- 02簡潔な件名と説明文の作成
- 03コミット前のメッセージ確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/git-commitを入力して読み込まれたか確認します。
詳細
Git コミットのガイドライン
このリポジトリでコミットを作成する際は、以下のルールに従ってください。
7 つのルール
- 件名と本文の間に空行を入れる
- 件名は 50 文字以内にする
- 件名の先頭を大文字にする
- 件名の末尾にピリオドを付けない
- 命令形を使う（「Add feature」のように。「Added feature」ではありません）
- 本文は 72 文字で折り返す
- 本文では方法ではなく、何を変更したか、なぜ変更したかを説明する
主な原則
簡潔に書き、冗長にならないようにします。 すべての語句に意味を持たせてください。実装の仕組みに関する不要な詳細は避け、何が変わったのか、そしてそれが重要な理由に焦点を当てます。
件名だけで内容が伝わるようにします。変更を理解するために本文を読む必要がないようにしてください。本文は任意であり、明らかでない背景を説明する場合にのみ必要です。
発見された経緯ではなく、変更内容に焦点を当てます。コミットメッセージで「レビューのフィードバック」、「PR のコメント」、「コードレビュー」には決して言及しないでください。誰かに依頼されたことではなく、変更内容とその理由を説明します。
箇条書きは避けます。リストではなく文章で書いてください。変更内容の説明に箇条書きが必要なら、一度にコミットする変更が多すぎるか、実装の詳細を説明しすぎています。
形式
適切な書式を保つため、必ず HEREDOC を使用します。
git commit -m "$(cat <<'EOF'
Subject line here
Optional body paragraph explaining what and why.
EOF
)"
良い例
Add session isolation for concurrent executions
Fix encoding parameter handling in file operations
The encoding parameter wasn't properly passed through the validation
layer, causing base64 content to be treated as UTF-8.
悪い例
Update files
Changes some things related to sessions and also fixes a bug.
問題：件名が曖昧で、何を変更したのかが説明されていません
Add file operations support
Implements FileClient with read/write methods and adds FileService
in the container with a validation layer. Includes comprehensive test
coverage for edge cases and supports both UTF-8 text and base64 binary
encodings. Uses proper error handling with custom error types from the
shared package for consistency across the SDK.
問題：実装の詳細を説明しすぎており、語数が多すぎます
コミット前のチェックリスト
- 件名が 50 文字以内
- 件名が命令形
- 件名の先頭が大文字で、末尾にピリオドがない
- 本文がある場合、方法ではなく理由を説明している
- レビューのフィードバックや PR のコメントに言及していない
- 本文に箇条書きがない
- 機密ファイル（.env、認証情報）をコミットしていない
コメント
Markdown 対応