Commit Helper
- 636 installs
- 65 repo stars
- Updated June 21, 2026
- charon-fan/agent-playbook
commit-helper is a Claude Code Git skill that generates Conventional Commits compliant messages from staged diffs for developers who need clear, scoped commit history without manual message formatting.
About
commit-helper is a Claude Code skill from charon-fan/agent-playbook in the agent-playbook collection. When asked to commit changes, the skill runs `git diff`, analyzes the patch, drafts a Conventional Commits message with type, optional scope, and subject line, presents it for approval, and executes the commit on confirmation. Examples include scoped messages like `feat(auth): add OAuth2 login support` for feature work. Developers reach for commit-helper during daily Git workflows when they want consistent commit semantics across teams following the Conventional Commits specification without writing messages manually.
- Automatically reviews git diff and generates Conventional Commits messages
- Follows feat, fix, chore, docs, refactor, style, test, and other Angular-style types
- Presents message for approval before executing git commit
- Includes validation script to enforce commit message format
- Reduces cognitive load when committing across frontend, backend, and infrastructure changes
Commit Helper by the numbers
- 636 all-time installs (skills.sh)
- Ranked #94 of 739 Git & Pull Requests skills by installs in the Skillselion catalog
- Security screen: LOW risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/charon-fan/agent-playbook --skill commit-helperAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 636 |
|---|---|
| repo stars | ★ 65 |
| Security audit | 3 / 3 scanners passed |
| Last updated | June 21, 2026 |
| Repository | charon-fan/agent-playbook ↗ |
How do you write Conventional Commits messages from a diff?
Generate Conventional Commits compliant messages that clearly communicate the intent and scope of every change.
Who is it for?
Developers using Conventional Commits who want agent-generated messages reviewed against actual git diff output before committing.
Skip if: Teams that do not use Conventional Commits, or workflows requiring squash-merge PR descriptions instead of per-commit message generation.
When should I use this skill?
The user asks to commit changes, write a commit message, or follow Conventional Commits after completing code edits.
What you get
Approved Conventional Commits message committed to Git history with proper type, scope, and subject formatting.
- Conventional Commits formatted message
- Executed git commit
Files
Commit Message Helper
A skill for creating properly formatted Git commit messages following the Conventional Commits specification.
When This Skill Activates
This skill activates when you:
- Ask to commit changes
- Mention commit messages
- Request git commit formatting
- Say "commit" or "git commit"
Commit Message Format
<type>(<scope>): <subject>
<body>
<footer>Types
| Type | Description |
|---|---|
feat | A new feature |
fix | A bug fix |
docs | Documentation only changes |
style | Changes that do not affect the meaning of the code (formatting, etc.) |
refactor | A code change that neither fixes a bug nor adds a feature |
perf | A code change that improves performance |
test | Adding missing tests or correcting existing tests |
chore | Changes to the build process or auxiliary tools |
ci | Changes to CI configuration files and scripts |
build | Changes that affect the build system or external dependencies |
Scope
The scope should indicate the area of the codebase affected:
- For frontend:
components,hooks,store,styles,utils - For backend:
api,models,services,database,auth - For devops:
ci,deploy,docker - Project-specific scopes are also acceptable
Guidelines
Subject Line
- Use imperative mood ("add feature" not "added feature" or "adds feature")
- No period at the end
- Maximum 50 characters
- Be specific and concise
Body
- Separate subject from body with a blank line
- Use the body to explain what and why, not how
- Wrap at 72 characters per line
- Mention any breaking changes
Footer
- Reference issues:
Closes #123,Fixes #456,Refs #789 - Multiple issues:
Closes #123, #456, #789 - Breaking changes: Start with
BREAKING CHANGE:followed by description
Examples
Good Examples
feat(auth): add OAuth2 login support
Implement OAuth2 authentication flow to allow users to log in
with their Google or GitHub accounts.
This change adds:
- New OAuth2 middleware for handling callbacks
- Updated login UI with social login buttons
- User profile synchronization
Closes #123fix(api): resolve race condition in user creation
The concurrent user creation requests could result in duplicate
email entries. Added unique constraint and proper error handling.
Fixes #456refactor(user): simplify profile update logic
Extracted common validation logic into a reusable function
to reduce code duplication across profile update endpoints.docs: update API documentation with new endpoints
Added documentation for the v2 user management endpoints
including request/response examples and error codes.Bad Examples
updated stuff # Too vague, no type/scope
fixed bug # No context about which bug
feat: added feature # Redundant ("feat" means new feature)
Feat(User): Add Login # Incorrect capitalization
feat: A really really really long subject line that exceeds the recommended limit # Too longBreaking Changes
When introducing breaking changes, add BREAKING CHANGE: to the footer:
feat(api): migrate to REST v2
The API endpoints have been restructured for better consistency.
Old endpoints are deprecated and will be removed in v3.0.
BREAKING CHANGE: `/api/v1/users` is now `/api/v2/users`.
All consumers must update their integration by 2025-03-01.Workflow
When writing a commit message:
1. Review changes - Run git diff to understand what changed 2. Identify type - Determine the type of change 3. Identify scope - Determine which area is affected 4. Write subject - Create a clear, concise subject line 5. Write body - Explain what and why (if needed) 6. Add footer - Reference issues or note breaking changes
Validation
Use the validation script to check commit message format:
python scripts/validate_commit.py "your commit message"Reference Documents
- See
references/conventional-commits.mdfor full specification - See
references/examples.mdfor more examples - See
references/scopes.mdfor recommended scope naming
Commit Helper
A Claude Code skill for writing Git commit messages following the Conventional Commits specification.
Installation
This skill is part of the agent-playbook collection.
Usage
When working with Git, simply ask Claude to commit your changes:
You: commit my changesThe skill will automatically: 1. Review your changes with git diff 2. Generate a properly formatted commit message 3. Present it for your approval 4. Execute the commit when confirmed
Examples
Simple Feature
You: Commit the new user authentication feature
Claude generates:
feat(auth): add OAuth2 login support
Implement OAuth2 authentication flow for Google and GitHub.
Users can now link multiple social accounts to their profile.Bug Fix
You: Commit the API timeout fix
Claude generates:
fix(api): resolve timeout in user endpoint
Added 30-second timeout to database query to prevent slow queries
from causing request timeouts.Validation
The skill includes a validation script to check commit message format:
python scripts/validate_commit.py "feat(api): add user endpoint"References
Conventional Commits Specification
Summary
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history.
Structure
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]Type
Must be one of the following:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing tests or correcting existing tests
- build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
- ci: Changes to CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
- chore: Other changes that don't modify src or test files
- revert: Reverts a previous commit
Scope
The scope should be the name of the npm package or module affected.
Description
The description contains a short description of the change:
- Use imperative, present tense: "change" not "changed" nor "changes"
- Don't capitalize the first letter
- No period (.) at the end
Body
Just as in the subject, use the imperative, present tense: "fix" not "fixed" nor "fixes".
Explain what and why instead of how.
Footer
The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.
Breaking Changes
A BREAKING CHANGE must be indicated in the footer. A BREAKING CHANGE must be a part of the type/scope or the description.
feat(api): remove deprecated endpoints
BREAKING CHANGE: The /api/v1/users endpoint has been removed.References
- https://www.conventionalcommits.org/
- https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format
Commit Message Examples
Features
feat(auth): add OAuth2 login support
Implement OAuth2 authentication flow supporting Google and GitHub
providers. Users can now link multiple social accounts to their profile.
Closes #123feat(components): add data table component
New reusable table component with built-in sorting, filtering, and
pagination. Uses TanStack Table for performance.Bug Fixes
fix(api): resolve race condition in user creation
Concurrent requests could create duplicate users. Added unique constraint
on email field with proper error handling.
Fixes #456fix(auth): prevent session token leakage
Session tokens were being logged in debug output. Removed sensitive
data from debug logs.Refactoring
refactor(user): extract validation logic
Moved user validation logic into a dedicated validator module to
enable reuse across different parts of the application.refactor(api): simplify error handling middleware
Unified error response format across all API endpoints.Documentation
docs: update installation guide with new requirements
Added Python 3.12 and Node.js 20 to the supported versions list.
Updated docker-compose examples.docs(api): add OpenAPI specification for v2 endpoints
Complete API documentation including request/response schemas and
authentication requirements.Performance
perf(api): add database query caching
Implemented Redis caching for frequently accessed data. Reduced
average response time from 200ms to 50ms.perf(frontend): lazy load images below fold
Implemented Intersection Observer for lazy loading. Reduced initial
page load by 40%.Breaking Changes
feat(api): migrate to REST v2
API endpoints have been restructured for better consistency.
Old v1 endpoints are deprecated.
BREAKING CHANGE: All `/api/v1/*` endpoints moved to `/api/v2/*`.
Migration guide: docs/api-migration-v1-to-v2.md
Closes #789Complex Example
feat(payment): integrate Stripe payment processing
Add comprehensive Stripe integration for subscription and one-time payments.
Includes webhook handling for payment events and automatic invoice generation.
Key features:
- Support for multiple payment methods (card, Apple Pay, Google Pay)
- Subscription lifecycle management
- Payment failure retry logic
- PCI-compliant card handling via Stripe Elements
Security considerations:
- All card data is handled directly by Stripe
- Webhook signatures are verified
- Sensitive payment data is never stored locally
Migration notes:
- Existing users need to add payment method
- Trial period extended by 14 days for existing users
Related tickets: FEAT-123, FEAT-124
Breaking Change: Old PayPal integration removedRecommended Scopes
Frontend
| Scope | Usage |
|---|---|
components | UI component changes |
hooks | Custom React hooks |
store | State management (Redux, Zustand, etc.) |
styles | CSS, styled-components, theme |
utils | Utility functions |
forms | Form-related changes |
routing | Route configuration |
Backend
| Scope | Usage |
|---|---|
api | API endpoints, controllers |
models | Data models, schemas |
services | Business logic services |
database | Database queries, migrations |
auth | Authentication, authorization |
middleware | Express/HTTP middleware |
validators | Input validation |
DevOps
| Scope | Usage |
|---|---|
ci | Continuous Integration (GitHub Actions, Jenkins) |
cd | Continuous Deployment |
docker | Dockerfile, docker-compose |
k8s | Kubernetes manifests |
terraform | Infrastructure as Code |
General
| Scope | Usage |
|---|---|
config | Configuration changes |
deps | Dependency updates |
tests | Test files (use test type for test code changes) |
types | TypeScript type definitions |
assets | Images, fonts, static files |
Project-Specific
Projects should define their own scopes based on their module structure. Document project-specific scopes in the project's CONTRIBUTING.md.
#!/usr/bin/env python3
"""
Validate commit message format against Conventional Commits specification.
"""
import re
import sys
def suggest_imperative(word: str) -> str:
if word.endswith("ied") and len(word) > 3:
return word[:-3] + "y"
if word.endswith("ed") and len(word) > 2:
base = word[:-2]
if base.endswith(("at", "it", "op", "er")):
return base[:-1]
return base
if word.endswith("ing") and len(word) > 3:
return word[:-3]
return word
def validate_commit_message(message: str) -> tuple[bool, str]:
"""
Validate a commit message against Conventional Commits format.
Args:
message: The commit message to validate
Returns:
(is_valid, error_message)
"""
if not message:
return False, "Commit message is empty"
lines = message.split('\n')
subject = lines[0]
# Validate subject line format: type(scope)!: subject
types = "feat|fix|docs|style|refactor|perf|test|chore|ci|build|revert"
pattern = rf'^({types})(\([A-Za-z0-9_.-]+\))?(!)?: .{{1,72}}$'
if not re.match(pattern, subject):
return False, (
"Invalid format. Expected: type(scope)!: subject\n"
"- Type must be one of: feat, fix, docs, style, refactor, perf, test, chore, ci, build, revert\n"
"- Subject must be 1-72 characters\n"
"- Use imperative mood (e.g., 'add feature' not 'added feature')"
)
# Check for period at end of subject
if subject.endswith('.'):
return False, "Subject line should not end with a period"
# Check subject uses imperative mood (basic check)
words = subject.split(': ', 1)[1].split() if ': ' in subject else []
if words:
first_word = words[0].lower()
# Common past tense indicators
if first_word.endswith(('ed', 'ing')):
suggestion = suggest_imperative(first_word)
return False, f"Subject should use imperative mood ('{first_word}' -> '{suggestion}')"
# Validate body format (if present)
if len(lines) > 1:
if lines[1].strip(): # No blank line after subject
return False, "Separate subject from body with a blank line"
body = '\n'.join(lines[2:])
for line in body.split('\n'):
if len(line) > 72:
return False, f"Body lines should wrap at 72 characters (found {len(line)})"
return True, "Valid commit message format"
if __name__ == "__main__":
if len(sys.argv) < 2:
print("Usage: python validate_commit.py \"commit message\"")
sys.exit(1)
message = sys.argv[1]
is_valid, result = validate_commit_message(message)
print(result)
sys.exit(0 if is_valid else 1)
Related skills
Caveman CommitGenerate terse, Conventional Commits messages that preserve intent without fluff or AI attribution.264k92.8k
Git Guardrails Claude CodePrevent Claude Code from accidentally running destructive git commands like force push, hard reset, or clean.164k187kResolving Merge ConflictsQuickly understand, resolve, and commit merge conflicts without losing work or breaking their flow.160k187k
Using Git WorktreesGuarantee every new feature or implementation task runs inside a clean, isolated workspace without polluting the main branch or current working directory.145k261k
Git CommitGenerate accurate conventional commit messages and intelligently stage files directly from natural language requests.40.2k37k
Resolve Merge ConflictsQuickly understand and resolve Git merge conflicts without losing context or breaking changes.15.6k147FAQ
What commit format does commit-helper follow?
commit-helper follows the Conventional Commits specification, producing messages with a type such as feat or fix, an optional parenthetical scope, and a concise subject line derived from the actual git diff.
Does commit-helper commit without approval?
commit-helper presents the generated Conventional Commits message for approval first, then executes the git commit only after the developer confirms the proposed type, scope, and subject.
Is Commit Helper safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.