オプション
家 Skill コードレビュー Git Commit Helper

git diff を分析して、説明的なコミットメッセージを生成します。ユーザーがコミットメッセージの作成やステージングされた変更の確認について助けを求めてきた際に使用してください。

...すべて拡張します
50
更新された時間 2026年6月29日

概要Git Commit Helper

「Git Commit Helper 」スキルは、Gitのdiffを分析することで、開発者が明確で説明的なコミットメッセージを作成できるよう支援することを目的としています。このスキルは、曖昧だったり構成が不十分だったりするコミットメッセージという一般的な問題に対処します。こうしたメッセージは混乱を招き、ソフトウェア開発プロジェクトにおけるコラボレーションの妨げとなる可能性があります。コミット用にステージングされた変更に基づいて提案を行うことで、メッセージが情報豊富であり、コミットメッセージの書式に関するベストプラクティスに従うことを保証します。

このスキルは、従来のコミット形式に従った、体系的なコミットメッセージ生成アプローチを特徴としています。変更内容を機能追加、バグ修正、ドキュメント更新などの具体的なタイプに分類し、効果的なコミットメッセージを作成するためのガイドラインを提供します。ユーザーはさまざまなgitコマンドを使用してステージングされた変更を分析し、状況に合わせたコミットメッセージの提案を受け取ることができ、結果としてバージョン管理の実践における明確さと品質を向上させることができます。

対象ユーザーには、ソフトウェア開発者、共同プロジェクトに取り組むチーム、およびコードベースのメンテナンスに携わるすべての方が含まれます。「Git Commit Helper 」は、コミットメッセージの品質を向上させ、ワークフローを効率化し、現在および将来の共同作業者にとって意味があり、理解しやすいバージョン管理履歴を確保したい方にとって特に有用です。

よくある質問

Git Commit Helper はどのように使えばよいですか?

'git diff --staged' を使用してステージングされた変更を分析し、その変更に基づいてコミットメッセージを生成することができます。

このスキルはすべてのGit環境に対応していますか?

はい、Git Commit Helper は、Gitコマンドをサポートするあらゆる環境で利用できます。

このスキルの使用に制限はありますか?

このスキルは、最適な結果を得るために、git コマンドの適切な使用と、標準的なコミット形式に依存しています。

コミットメッセージの形式をカスタマイズすることはできますか?

このスキルは標準的な形式に従っていますが、生成されたメッセージは必要に応じて調整できます。

コミットする変更が複数ある場合はどうなりますか?

複数ファイルのコミットに関するガイドラインを参照して、メッセージを効果的に構成することができます。

GitHubで見る

Git Commit Helper

Quick start

Analyze staged changes and generate commit message:

# View staged changesgit diff --staged# Generate commit message based on changes# (Claude will analyze the diff and suggest a message)

Commit message format

Follow conventional commits format:

<type>(<scope>): <description>[optional body][optional footer]

Types

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation changes
  • style: Code style changes (formatting, missing semicolons)
  • refactor: Code refactoring
  • test: Adding or updating tests
  • chore: Maintenance tasks

Examples

Feature commit:

feat(auth): add JWT authenticationImplement JWT-based authentication system with:- Login endpoint with token generation- Token validation middleware- Refresh token support

Bug fix:

fix(api): handle null values in user profilePrevent crashes when user profile fields are null.Add null checks before accessing nested properties.

Refactor:

refactor(database): simplify query builderExtract common query patterns into reusable functions.Reduce code duplication in database layer.

Analyzing changes

Review what's being committed:

# Show files changedgit status# Show detailed changesgit diff --staged# Show statisticsgit diff --staged --stat# Show changes for specific filegit diff --staged path/to/file

Commit message guidelines

DO:

  • Use imperative mood ("add feature" not "added feature")
  • Keep first line under 50 characters
  • Capitalize first letter
  • No period at end of summary
  • Explain WHY not just WHAT in body

DON'T:

  • Use vague messages like "update" or "fix stuff"
  • Include technical implementation details in summary
  • Write paragraphs in summary line
  • Use past tense

Multi-file commits

When committing multiple related changes:

refactor(core): restructure authentication module- Move auth logic from controllers to service layer- Extract validation into separate validators- Update tests to use new structure- Add integration tests for auth flowBreaking change: Auth service now requires config object

Scope examples

Frontend:

  • feat(ui): add loading spinner to dashboard
  • fix(form): validate email format

Backend:

  • feat(api): add user profile endpoint
  • fix(db): resolve connection pool leak

Infrastructure:

  • chore(ci): update Node version to 20
  • feat(docker): add multi-stage build

Breaking changes

Indicate breaking changes clearly:

feat(api)!: restructure API response formatBREAKING CHANGE: All API responses now follow JSON:API specPrevious format:{ "data": {...}, "status": "ok" }New format:{ "data": {...}, "meta": {...} }Migration guide: Update client code to handle new response structure

Template workflow

  1. Review changes: git diff --staged
  2. Identify type: Is it feat, fix, refactor, etc.?
  3. Determine scope: What part of the codebase?
  4. Write summary: Brief, imperative description
  5. Add body: Explain why and what impact
  6. Note breaking changes: If applicable

Interactive commit helper

Use git add -p for selective staging:

# Stage changes interactivelygit add -p# Review what's stagedgit diff --staged# Commit with messagegit commit -m "type(scope): description"

Amending commits

Fix the last commit message:

# Amend commit message onlygit commit --amend# Amend and add more changesgit add forgotten-file.jsgit commit --amend --no-edit

Best practices

  1. Atomic commits - One logical change per commit
  2. Test before commit - Ensure code works
  3. Reference issues - Include issue numbers if applicable
  4. Keep it focused - Don't mix unrelated changes
  5. Write for humans - Future you will read this

Commit message checklist

  • Type is appropriate (feat/fix/docs/etc.)
  • Scope is specific and clear
  • Summary is under 50 characters
  • Summary uses imperative mood
  • Body explains WHY not just WHAT
  • Breaking changes are clearly marked
  • Related issue numbers are included

すべてのファイル

1件のファイル

Git Commit Helperをインストール

スキルファイルをダウンロードし、.claude/skills/ ディレクトリに解凍してください。

ZIPをダウンロード

リポジトリをクローンし、スキルファイルをプロジェクトにコピーしてください。

git clone https://github.com/davila7/claude-code-templates/blob/main/cli-tool/components/skills/development/git-commit-helper/SKILL.md # Copy SKILL.md to your .claude/skills/ directory

コピー コピー
クイックセットアップ: skill フォルダを .claude/skills/ にコピーしてください。Claude が自動的にそのスキルを検出して使用します。

関連スキル

code-simplify
更新された時間 2026年7月2日
requesting-code-review
更新された時間 2026年6月29日
commit-standards
更新された時間 2026年6月29日
fetch-pr-review-comments
更新された時間 2026年6月29日
OR