コミットメッセージガイド

このスキルは、コミットメッセージが従来型のコミット形式に従い、命令形の時制を使い、簡潔で意味のある内容であることを保証します。

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

形式

<type>(<scope>): <subject>

[optional body]

[optional footer]

Type（型）

以下の従来型のコミット型から選択してください：

• feat: 新機能
• fix: バグ修正
• refactor: バグ修正でも機能追加でもないコード変更
• perf: パフォーマンス改善
• style: コードスタイルの変更（フォーマット、セミコロンの欠落など）
• test: テストの追加または更新
• docs: ドキュメントの変更
• build: ビルドシステムまたは依存関係の変更
• ci: CI/CD設定の変更
• chore: src またはテストファイルを変更しないその他の変更

Scope（スコープ）（オプション）

スコープはコードベースのどの領域が影響を受けるかについてのコンテキストを提供します。変更されるモジュール/コンポーネントに適切なスコープを使用してください。例：

• api, auth, db, ui, config, cli, core

Subject（サブジェクト）

• 命令形を使用してください：「Added feature」や「Adds feature」ではなく「Add feature」
• 簡潔に保つ（理想的には50文字以下、最大72文字）
• 末尾にピリオドをつけない
• 型プレフィックスの後は小文字で始める

例：

• feat(api): add support for batch operations
• fix(auth): handle expired token refresh
• refactor(db): simplify query builder logic

悪い例：

• feat(api): Added support for batch operations（間違った時制）
• Fixed a bug in auth（型/スコープが不足、時制が間違っている）

本文のガイドライン

タイトルとファイル変更だけではコミットの理由を適切に伝えられない場合にのみ、本文を含めてください。

含めるべき内容

• なぜ変更が行われたのか（明白でない場合）
• アーキテクチャ上の決定とその根拠
• 検討されたトレードオフ
• 差分では見えないコンテキスト

含めてはいけない内容

• GitHub上で見える情報（変更されたファイル、追加/削除された行、差分統計）
• テスト状態情報（「すべてのテストが成功」）
• 時間関連の情報（推定、費やした時間）
• 明白な情報（差分で見える実装の詳細）
• AI作成による帰属（「Claude Codeで生成」、Co-Authored-Byタグ、絵文字、ツール帰属なし）

良い本文の例

feat(api): add support for webhook callbacks

Implements webhook delivery for event notifications.
Uses a retry queue with exponential backoff to handle
transient failures without losing events.

refactor(db): restructure query parser

Reorganizes query parsing to use a table-driven approach
instead of a large switch statement. This makes it easier
to add new query types and reduces code duplication.

悪い本文の例

fix(auth): correct token expiry handling

Changes 3 files with 45 additions and 12 deletions.
All tests pass.
This fix took longer than expected, about 2 days.

特殊なコミット型

WIPコミット

WIP: debugging race condition in scheduler

これらは厳密なフォーマットに従う必要がなく、テストが失敗していることもあります。

FIXUPコミット

fixup! feat(api): add support for webhook callbacks

git commit --fixup=<commit-hash> で作成され、リベース時に自動的にスカッシュされます。

プリコミットチェックリスト

コミットを作成する前に、以下を確認してください：

• GitHubアカウント: claude/references/github-auth-probe.md のアカウントプローブに従って確認（{owner}/{repo} を抽出、gh api でプローブし、必要に応じてアカウントを切り替える）
• コードが正常にビルドされること
• すべてのテストが成功していること
• コードがフォーマットされていること（フォーマッタを実行）
• コードがリントされていること（該当する場合）
• コミット型が適切であること
• サブジェクトが命令形を使用していること
• サブジェクトが簡潔で明確であること
• 本文（存在する場合）が差分以上の価値を追加していること
• 本文がGitHub上で見える情報を含んでいないこと
• 本文がテスト状態や時間推定を含んでいないこと
• AI帰属、コオーサータグ、またはツール帰属がないこと

例外: WIPまたはFIXUPコミットはこれらの要件をスキップできます。

例

最小限のコミット（本文不要）

feat(ui): add variable binding display command

タイトルで何が追加されたかが明確に説明されています。差分は実装を示します。

有用な本文を含むコミット

perf(core): optimize instruction dispatch loop

Replace computed goto with direct threaded code. This
reduces dispatch overhead by eliminating one memory
indirection per instruction. Trade-off is slightly
larger binary size due to code duplication.

不要な本文を含むコミット

fix(db): handle empty name table

Modified src/db.zig to add a check for empty tables.
Updated tests to cover this edge case. All 47 tests pass.
This was a quick fix, only took about an hour.

この情報は何も価値を追加していません。

コミット作成時

1. このガイドに従ってコミットメッセージを作成する
2. ドラフトをコミット前にユーザーに表示する
3. コミットが複雑な場合や複数の関心事に触れる場合はフィードバックを求める
4. 本文が価値を追加することを確認する - 判断に迷ったら本文を省略する
5. 本文には関連するコンテキストのみを含める
6. AI帰属を追加しない - いかなる種類のツール帰属も禁止
7. 複数の -m フラグを使用してコミットする -- git commitコマンドで $(...) またはヒアドック形式を使用しない：
   • サブジェクトのみ：git commit -m "type(scope): subject"
   • サブジェクト＋本文：git commit -m "type(scope): subject" -m "Body paragraph."
   • サブジェクト＋本文＋フッター：git commit -m "type(scope): subject" -m "Body paragraph." -m "BREAKING CHANGE: description"