Commit Helper

Generate high-quality commit messages that follow best practices and conventional commit standards.

When to Use This Skill

• User asks to "commit" or "write a commit message"
• User has staged changes and wants help describing them
• User asks about conventional commits or commit standards

Instructions

1. Analyze the changes:

   git diff --staged
   git status
   git log --oneline -5  # For context on commit style
   

2. Structure the message:

   • Subject line: Under 50 characters, imperative mood
   • Body (if needed): Wrap at 72 characters, explain WHY not WHAT
   • Footer (if needed): Breaking changes, issue references

3. Use conventional commit types:

   • feat: New feature
   • fix: Bug fix
   • docs: Documentation only
   • style: Formatting, no code change
   • refactor: Code change without feature/fix
   • perf: Performance improvement
   • test: Adding/correcting tests
   • chore: Build process, auxiliary tools

Format

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

<optional body>

<optional footer>

Examples

Simple fix:

fix(auth): prevent null pointer in token validation

Feature with body:

feat(api): add rate limiting to public endpoints

Implements token bucket algorithm with configurable limits.
Default: 100 requests per minute per IP.

Closes #234

Breaking change:

refactor!: change config file format to JSONC

BREAKING CHANGE: Config files must now use .jsonc extension.
Run `migrate-config` to update existing configs.

Best Practices

• Use present tense ("add feature" not "added feature")
• Use imperative mood ("move cursor" not "moves cursor")
• Don't end the subject line with a period
• Explain WHY the change was made, not just WHAT changed
• Reference issues/PRs when relevant
• Keep commits atomic (one logical change per commit)