git-style-commit
Gitのコミット履歴を分析して既存のスタイルに合わせたコミットメッセージを作成したり、ステージングされた変更をコミットしたりするなど、リポジトリのスタイルに沿ったコミット作業を支援するSkill。
📜 元の英語説明(参考)
Analyze git history for commit style, stage changes, and commit without pushing. Use when the user wants to commit changes with a message that matches their repository's existing commit style, or when they ask to commit staged/unstaged changes.
🇯🇵 日本人クリエイター向け解説
Gitのコミット履歴を分析して既存のスタイルに合わせたコミットメッセージを作成したり、ステージングされた変更をコミットしたりするなど、リポジトリのスタイルに沿ったコミット作業を支援するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o git-style-commit.zip https://jpskill.com/download/10462.zip && unzip -o git-style-commit.zip && rm git-style-commit.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/10462.zip -OutFile "$d\git-style-commit.zip"; Expand-Archive "$d\git-style-commit.zip" -DestinationPath $d -Force; ri "$d\git-style-commit.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
git-style-commit.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
git-style-commitフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
Git スタイル対応コミット
このスキルは、リポジトリのコミット履歴を分析して、一般的なコミットメッセージのスタイルを特定し、変更をステージングして、そのスタイルに一致するメッセージでコミットを作成します。
このスキルの使用時
- リポジトリの慣例に一致するメッセージで変更をコミットする場合
- ファイルのステージングとコミット(特定のファイルまたはすべての変更)
- コミットメッセージがチーム/プロジェクトの標準に従っていることを確認する場合
- 既存のスタイルパターンを尊重しながら、コミットの作成を自動化する場合
使用方法
基本的な使用法
Commit these changes
Stage and commit src/utils.ts
Commit all changes matching the repo style
特定のファイルを使用する場合
Commit FILES="src/components/Button.tsx src/styles/button.css"
指示
ユーザーが変更のコミットを要求した場合:
1. コミットスタイルの分析
git log -n 10 --pretty=format:"%s" を実行して、最新の10件のコミットメッセージを確認します。
一般的なスタイルパターンを特定します。
- Conventional Commits:
feat:,fix:,chore:,docs:など - 大文字化: 文頭のみ大文字、タイトルケース、または小文字
- 時制: 現在形("Add feature")または過去形("Added feature")
- 絵文字の使用: 絵文字の有無と種類(🎨, ✨, 🐛など)
- 形式: 単一行か、本文を含む複数行か
- プレフィックス/サフィックス: 一貫したプレフィックスまたはサフィックス
検出するパターン例:
feat: add user authentication(Conventional Commits, 小文字)Fix bug in login flow(プレフィックスなし, タイトルケース, 現在形)✨ Add dark mode toggle(絵文字プレフィックス, タイトルケース)[API] Update endpoint documentation(ブラケットプレフィックス, タイトルケース)
2. 変更のステージング
FILES 引数で特定のファイルが指定されている場合:
git add $FILES
それ以外の場合は、すべての変更をステージングします:
git add -A
次に、コミットされる内容を確認します:
git diff --staged
# or
git diff --cached
ステージングされた変更を分析して、以下を理解します。
- どのファイルが変更されたか
- 変更の種類(追加、削除、修正)
- 変更の範囲と性質
3. コミットメッセージの生成
以下を満たす、簡潔なコミットメッセージを1つ作成します。
- ステージングされた変更を正確に記述する
- 非常に重要: ステップ1で特定されたスタイルパターンに一致する
スタイル一致の例:
履歴が Conventional Commits を示している場合:
feat: add user profile editing
fix: resolve memory leak in cache
chore: update dependencies
履歴が絵文字プレフィックスを示している場合:
✨ Add user profile editing
🐛 Fix memory leak in cache
📦 Update dependencies
履歴がプレフィックスなし、タイトルケースを示している場合:
Add user profile editing
Fix memory leak in cache
Update dependencies
メッセージ生成のガイドライン:
- 簡潔に保つ(理想的には件名行は72文字未満)
- リポジトリのパターンと同じ時制を使用する
- 大文字化のスタイルを正確に一致させる
- プレフィックス/絵文字パターンが存在する場合は、同じものを含める
- なぜ変更されたかではなく、何が変更されたかに焦点を当てる(スタイルに「理由」が含まれている場合を除く)
4. コミット
生成されたメッセージでコミットを実行します。
git commit -m "YOUR_GENERATED_MESSAGE"
5. 安全性制約
PUSH しないでください。コミットが作成された直後に停止します。
ユーザーによる検証のために使用された最終的なコミットメッセージを出力します。
✅ Committed with message: "feat: add user profile editing"
例
例 1: Conventional Commits スタイル
リポジトリの履歴:
feat: add authentication middleware
fix: resolve CORS issue
docs: update API documentation
chore: bump version to 1.2.0
ステージングされた変更: 新しい Button.tsx コンポーネントを追加
生成されたメッセージ: feat: add Button component
例 2: 絵文字スタイル
リポジトリの履歴:
✨ Add dark mode support
🐛 Fix login redirect loop
📝 Update README
ステージングされた変更: フォーム検証のバグを修正
生成されたメッセージ: 🐛 Fix form validation bug
例 3: シンプルなタイトルケース
リポジトリの履歴:
Add user dashboard
Fix API timeout issue
Update dependencies
ステージングされた変更: ヘルパー関数を追加するために utils.ts を修正
生成されたメッセージ: Add helper functions to utils
例 4: ブラケットプレフィックススタイル
リポジトリの履歴:
[Frontend] Add responsive navigation
[Backend] Fix database connection pool
[Docs] Update installation guide
ステージングされた変更: api/users.ts の API エンドポイントを更新
生成されたメッセージ: [Backend] Update users API endpoint
一般的なパターン
Conventional Commits
feat:- 新機能fix:- バグ修正docs:- ドキュメントの変更style:- コードスタイルの変更(フォーマット、セミコロンの欠落など)refactor:- コードのリファクタリングtest:- テストの追加または更新chore:- メンテナンス作業、依存関係の更新
絵文字パターン
- 🎨 - コードスタイル/フォーマット
- ✨ - 新機能
- 🐛 - バグ修正
- 📝 - ドキュメント
- 🔥 - コード/ファイルの削除
- 💚 - テストの修正
- 🚀 - パフォーマンスの改善
- 🔒 - セキュリティ修正
エラー処理
コミット履歴が存在しない場合:
- デフォルトのスタイルを使用する(変更の種類に基づいて
feat:またはfix:を使用した Conventional Commits) - ユーザーに通知する: "コミット履歴が見つかりませんでした。Conventional Commits 形式を使用します"
ステージングが失敗した場合:
- ファイルが存在するかどうかを確認する:
git status - 特定のエラーをユーザーに報告する
- コミットに進まない
コミットが失敗した場合:
- ステージング領域が空でないか確認する:
git diff --stagedで変更が表示されるはずです - git リポジトリが初期化されていることを確認する
- エラーを報告し、自動的に再試行しない
ベストプラクティス
- 常に最初にスタイルを分析する - スタイルパターンを想定しない
- 正確に一致させる - 履歴が小文字を使用している場合は小文字を使用し、タイトルケースを使用している場合はタイトルケースを使用する
- 記述的にする - メッセージは何が変更されたかを明確に示す必要がある
- スコープを尊重する - Conventional Commits が使用されている場合は、適切なスコープを含める:
feat(auth): add login - 決してプッシュしない - このスキルはコミットを作成するだけで、プッシュは決して行わない
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Git Style-Aware Commit
This skill analyzes your repository's commit history to identify the prevailing commit message style, then stages changes and creates a commit with a message that matches that style.
When to Use This Skill
- Committing changes with a message that matches repository conventions
- Staging and committing files (specific files or all changes)
- Ensuring commit messages follow team/project standards
- Automating commit creation while respecting existing style patterns
How to Use
Basic Usage
Commit these changes
Stage and commit src/utils.ts
Commit all changes matching the repo style
With Specific Files
Commit FILES="src/components/Button.tsx src/styles/button.css"
Instructions
When a user requests to commit changes:
1. Analyze Commit Style
Run git log -n 10 --pretty=format:"%s" to review the last 10 commit messages.
Identify the prevailing style pattern:
- Conventional Commits:
feat:,fix:,chore:,docs:, etc. - Capitalization: Sentence case, title case, or lowercase
- Tense: Present tense ("Add feature") or past tense ("Added feature")
- Emoji usage: Presence and type of emojis (🎨, ✨, 🐛, etc.)
- Format: Single line vs multi-line with body
- Prefixes/suffixes: Any consistent prefixes or suffixes
Example patterns to detect:
feat: add user authentication(Conventional Commits, lowercase)Fix bug in login flow(No prefix, title case, present tense)✨ Add dark mode toggle(Emoji prefix, title case)[API] Update endpoint documentation(Bracket prefix, title case)
2. Stage Changes
If specific files are provided via FILES argument:
git add $FILES
Otherwise, stage all changes:
git add -A
Then review what will be committed:
git diff --staged
# or
git diff --cached
Analyze the staged changes to understand:
- What files were modified
- What types of changes (additions, deletions, modifications)
- The scope and nature of the changes
3. Generate Commit Message
Draft a single, concise commit message that:
- Accurately describes the staged changes
- CRITICALLY: Matches the style pattern identified in step 1
Style matching examples:
If history shows Conventional Commits:
feat: add user profile editing
fix: resolve memory leak in cache
chore: update dependencies
If history shows emoji prefixes:
✨ Add user profile editing
🐛 Fix memory leak in cache
📦 Update dependencies
If history shows no prefix, title case:
Add user profile editing
Fix memory leak in cache
Update dependencies
Message generation guidelines:
- Keep it concise (ideally under 72 characters for the subject line)
- Use the same tense as the repository pattern
- Match capitalization style exactly
- Include the same prefix/emoji pattern if present
- Focus on what changed, not why (unless the style includes "why")
4. Commit
Run the commit with the generated message:
git commit -m "YOUR_GENERATED_MESSAGE"
5. Safety Constraint
DO NOT PUSH. Stop immediately after the commit is created.
Print the final commit message used for user verification:
✅ Committed with message: "feat: add user profile editing"
Examples
Example 1: Conventional Commits Style
Repository history:
feat: add authentication middleware
fix: resolve CORS issue
docs: update API documentation
chore: bump version to 1.2.0
Staged changes: Added new Button.tsx component
Generated message: feat: add Button component
Example 2: Emoji Style
Repository history:
✨ Add dark mode support
🐛 Fix login redirect loop
📝 Update README
Staged changes: Fixed bug in form validation
Generated message: 🐛 Fix form validation bug
Example 3: Simple Title Case
Repository history:
Add user dashboard
Fix API timeout issue
Update dependencies
Staged changes: Modified utils.ts to add helper functions
Generated message: Add helper functions to utils
Example 4: Bracket Prefix Style
Repository history:
[Frontend] Add responsive navigation
[Backend] Fix database connection pool
[Docs] Update installation guide
Staged changes: Updated API endpoint in api/users.ts
Generated message: [Backend] Update users API endpoint
Common Patterns
Conventional Commits
feat:- New featurefix:- Bug fixdocs:- Documentation changesstyle:- Code style changes (formatting, missing semicolons, etc.)refactor:- Code refactoringtest:- Adding or updating testschore:- Maintenance tasks, dependency updates
Emoji Patterns
- 🎨 - Code style/formatting
- ✨ - New feature
- 🐛 - Bug fix
- 📝 - Documentation
- 🔥 - Remove code/files
- 💚 - Fix tests
- 🚀 - Performance improvements
- 🔒 - Security fixes
Error Handling
If no commit history exists:
- Use a default style (Conventional Commits with
feat:orfix:based on change type) - Inform the user: "No commit history found, using Conventional Commits format"
If staging fails:
- Check if files exist:
git status - Report specific error to user
- Do not proceed with commit
If commit fails:
- Check for empty staging area:
git diff --stagedshould show changes - Verify git repository is initialized
- Report error and do not retry automatically
Best Practices
- Always analyze style first - Don't assume a style pattern
- Match exactly - If history uses lowercase, use lowercase; if it uses title case, use title case
- Be descriptive - The message should clearly indicate what changed
- Respect scope - If Conventional Commits are used, include appropriate scope:
feat(auth): add login - Never push - This skill only creates commits, never pushes them