Commit Helper
Turn diffs into focused, review-friendly commits and messages that explain intent.
When to Use
- You need a concise, meaningful commit message.
- A diff contains unrelated changes that should be split.
- You want commit text that helps reviewers and future debugging.
Conventional Commits Deep Dive
Type and scope: Use type(scope): subject - e.g., feat(auth): add OAuth callback, fix(api): handle null response. Types: feat, fix, refactor, docs, test, chore, style, perf. Scope is optional but helps group changes (module, package, or area).
Breaking patterns: Use BREAKING CHANGE: in the body or append ! after type/scope: feat(api)!: remove deprecated endpoint. Always document migration steps in the body.
Footer conventions: Use Refs: #123 or Closes #123 for issue references. Use Co-authored-by: Name <email> for pair commits. Use Signed-off-by: when required by DCO.
Commit Splitting Techniques
- git add -p: Stage hunks interactively (
git add -p <file>) to separate logical changes. Review each hunk; split further with s (split) when needed.
- Interactive rebase for reordering: Use
git rebase -i HEAD~N to reorder, squash, or edit commits. Use edit to pause, amend, then git rebase --continue. Never rebase shared branches without coordination.
Commit Message Anti-Patterns and Fixes
| Anti-pattern |
Fix |
| "fix stuff", "update", "misc" |
Use specific type and scope: fix(login): resolve redirect loop |
| Body repeats diff line-by-line |
Describe intent, impact, and why; omit implementation detail |
| No breaking change note |
Add BREAKING CHANGE: and migration steps when API/behavior changes |
| Subject over 72 chars |
Shorten; move detail to body |
| Mixed languages |
Use project default (usually English) consistently |
Common Pitfalls
- Giant commits mixing refactor+feature: Split with
git add -p or interactive rebase. One commit per logical change.
- Misleading commit types: Using
fix for refactors or feat for config tweaks. Match type to actual impact.
- Empty commit messages from squash merges: Configure squash to preserve or combine commit messages; avoid single-line "Merge" when meaningful history matters.
- Committing generated files: Exclude build artifacts, lockfiles (when not intentional), and secrets. Use
.gitignore and pre-commit hooks.
Workflow
- Inspect staged/unstaged changes and identify logical change groups.
- Determine commit type and scope (feature, fix, refactor, docs, test, chore).
- Draft subject line:
- Imperative mood
- Specific scope
- No vague terms like "update stuff"
- Add body for why/impact when change is non-trivial.
- Include breaking change or migration notes when applicable.
- Suggest commit splitting if changes mix unrelated concerns.
- Verify message matches actual diff contents.
Message Checklist
Output Format
Return:
- Recommended commit grouping strategy: Which changes belong together and in what order.
- Final commit message(s): One per logical commit, in Conventional Commits format with optional body and footers.
- Optional alternative phrasings: Shorter or more detailed variants.
- Risks or missing checks: Breaking changes, files to exclude, tests to run before push.
- Splitting guidance: If split needed, exact
git add -p or rebase steps.
Constraints
- Do not invent work not present in the diff.
- Avoid generic subjects ("misc fixes", "changes").
- Keep one commit focused on one logical purpose.
1---2name: commit-helper3description: Use this skill when turning actual code changes into focused commit plans or commit messages, splitting unrelated changes, applying Conventional Commits, or adding reviewer-ready scope and risk notes.4---56# Commit Helper78Turn diffs into focused, review-friendly commits and messages that explain intent.910## When to Use1112- You need a concise, meaningful commit message.13- A diff contains unrelated changes that should be split.14- You want commit text that helps reviewers and future debugging.1516## Conventional Commits Deep Dive1718**Type and scope:** Use `type(scope): subject` - e.g., `feat(auth): add OAuth callback`, `fix(api): handle null response`. Types: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `style`, `perf`. Scope is optional but helps group changes (module, package, or area).1920**Breaking patterns:** Use `BREAKING CHANGE:` in the body or append `!` after type/scope: `feat(api)!: remove deprecated endpoint`. Always document migration steps in the body.2122**Footer conventions:** Use `Refs: #123` or `Closes #123` for issue references. Use `Co-authored-by: Name <email>` for pair commits. Use `Signed-off-by:` when required by DCO.2324## Commit Splitting Techniques2526- **git add -p:** Stage hunks interactively (`git add -p <file>`) to separate logical changes. Review each hunk; split further with `s` (split) when needed.27- **Interactive rebase for reordering:** Use `git rebase -i HEAD~N` to reorder, squash, or edit commits. Use `edit` to pause, amend, then `git rebase --continue`. Never rebase shared branches without coordination.2829## Commit Message Anti-Patterns and Fixes3031| Anti-pattern | Fix |32|--------------|-----|33| "fix stuff", "update", "misc" | Use specific type and scope: `fix(login): resolve redirect loop` |34| Body repeats diff line-by-line | Describe intent, impact, and why; omit implementation detail |35| No breaking change note | Add `BREAKING CHANGE:` and migration steps when API/behavior changes |36| Subject over 72 chars | Shorten; move detail to body |37| Mixed languages | Use project default (usually English) consistently |3839## Common Pitfalls4041- **Giant commits mixing refactor+feature:** Split with `git add -p` or interactive rebase. One commit per logical change.42- **Misleading commit types:** Using `fix` for refactors or `feat` for config tweaks. Match type to actual impact.43- **Empty commit messages from squash merges:** Configure squash to preserve or combine commit messages; avoid single-line "Merge" when meaningful history matters.44- **Committing generated files:** Exclude build artifacts, lockfiles (when not intentional), and secrets. Use `.gitignore` and pre-commit hooks.4546## Workflow47481. Inspect staged/unstaged changes and identify logical change groups.492. Determine commit type and scope (feature, fix, refactor, docs, test, chore).503. Draft subject line:51 - Imperative mood52 - Specific scope53 - No vague terms like "update stuff"544. Add body for why/impact when change is non-trivial.555. Include breaking change or migration notes when applicable.566. Suggest commit splitting if changes mix unrelated concerns.577. Verify message matches actual diff contents.5859## Message Checklist6061- [ ] Subject is under ~72 characters and unambiguous.62- [ ] Body explains intent and behavior impact, not line-by-line edits.63- [ ] Any risks, follow-ups, or migration steps are captured.64- [ ] Commit does not include accidental generated/secrets files.6566## Output Format6768Return:6970- **Recommended commit grouping strategy:** Which changes belong together and in what order.71- **Final commit message(s):** One per logical commit, in Conventional Commits format with optional body and footers.72- **Optional alternative phrasings:** Shorter or more detailed variants.73- **Risks or missing checks:** Breaking changes, files to exclude, tests to run before push.74- **Splitting guidance:** If split needed, exact `git add -p` or rebase steps.7576## Constraints7778- Do not invent work not present in the diff.79- Avoid generic subjects ("misc fixes", "changes").80- Keep one commit focused on one logical purpose.
ChatAndBuild