committing-with-guidelines について
作業ツリーの変更を、レビューしやすいアトミックなコミット列にまとめるGitワークフロー用スキルです。変更の確認、計画、ステージング、検証、意図が伝わるメッセージ作成を案内します。
主な機能
- 01作業ツリーの変更を確認
- 02依存関係に沿ったコミット計画
- 03論理単位ごとのステージング
- 04ステージ済み変更の検証
- 05成果を示すコミットメッセージ作成
活用シーン
- 01混在した変更を別々のコミットに分割
- 02コードレビュー向けのコミット列を準備
- 03コミット前にステージ内容を確認
- 04明白でない変更の理由を記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/committing-with-guidelinesを入力して読み込まれたか確認します。
同梱ファイルEXAMPLES.md
詳細
ストーリー重視のコミット
レビューしやすい、粒度の細かいコミットの一連の流れを作成します。各コミットには、プロダクトまたはアーキテクチャ上の成果を1つ記録し、後から読む人がその理由を理解できるだけの説明を含めます。
ワークフロー
1. ワークツリーを確認する
最低限、次の項目を確認します。
git status --short
git diff
git diff --cached
リポジトリの慣習がこのスキルより厳格である可能性がある場合は、最近のコミットの件名を確認します。生成されたファイル、無関係な編集、コミットせずに残す変更を特定します。
完了条件： 変更されたすべてのパスが、提案されたコミットのいずれかに含まれるか、明示的に除外されています。
2. ストーリーを計画する
依存関係と、レビュアーが変更を理解していく順序に沿ってコミットを並べます。関連するテストやドキュメントも含めながら、各コミットを1つの論理的な成果にまとめます。同じファイルに変更があっても、無関係な成果は分割します。
複数のコミットがある場合は、ステージングする前に提案する順序を示します。
完了条件： 変更されたすべてのハンクに行き先が1つあり、各コミットが単独で成立します。
3. 1つの単位をステージする
対象のパスを正確に指定するか、パッチモードを使用します。
git add path/to/file
git add -p
次に、ステージされた内容を確認します。
git diff --cached --stat
git diff --cached
ワークツリー全体の確認を済ませてから、広範囲のステージングを行います。
完了条件： インデックスに含まれるのは、関連するテストやドキュメントを含む、1つの論理的な成果だけです。
4. ステージされた変更を検証する
リポジトリに関連するテスト、リンター、チェックを実行します。コミットをカバーする範囲で最も限定的なチェックを選び、プロジェクトの指示で必要とされている場合は、より広範なチェックも追加します。
完了条件： 必須のチェックに合格しているか、失敗したチェックと、コミットを進めるべきかどうかの理由をユーザーが把握しています。
5. コミットメッセージを作成してコミットする
次の構成を使用します。
<Action> <product-focused outcome>
- <decision, rationale, user impact, or trade-off>
- <additional context only when it helps a future reader>
件名
Add、Update、Remove、またはDeleteで始めます。- 現在形を使い、具体的な成果を示します。
- 件名は72文字未満を目安にします。
- ファイルやクラスではなく、プロダクトまたはアーキテクチャについて説明します。
- リポジトリでコミットへの記載が必須でない限り、チケット番号はブランチ名に含めます。
例：
Add team filtering to the progress dashboard
Update notification delivery to support multiple channels
Remove deprecated user-preference endpoints
本文
差分から理由、影響、トレードオフが明らかでない場合は、本文を追加します。異なる判断事項は箇条書きにします。次の点を説明します。
- なぜこの変更がこの形になったのか。
- プロダクトやユーザーへの影響。
- アーキテクチャ上の影響。
- 重要なトレードオフ。
実装内容の一覧、定型的なテストの追加、AI のクレジットや共著者の記載は省きます。実装の記録は差分に残し、意図はコミットメッセージに記録します。
コミットする前に、ステージされた差分をもう一度読み、その内容だけをもとにメッセージを作成します。
完了条件： メッセージが、ステージされた成果と、差分からは明らかでない理由を正確に説明しています。
6. 確認して次に進む
各コミットの後、git status --short と新しいコミットを確認します。次に計画した単位について、ワークフローを繰り返します。
完了条件： 意図した順序でコミットが作成され、各コミットが単独で理解でき、残りの変更も把握されています。
履歴の安全性
公開済みの履歴は変更不可として扱います。ユーザーが履歴の編集を依頼し、コミットを書き換えても安全だと確認した場合に限り、並べ替え、スカッシュ、アメンド、または強制プッシュを行います。--force より --force-with-lease を優先します。
混在したワークツリーの分割、メッセージの改善、未公開コミットの並べ替えについての実例は、EXAMPLES.md を参照してください。