Commit
Group unstaged changes into atomic commits by concern, matching repository style.
by helderberto · MIT
The skill
Group unstaged changes into atomic commits by concern, matching repository style. Use when asked to "commit", "create a commit", or "commit changes". Don't use for pushing or pull requests (/to-pr).
Git Commit
Group all unstaged/untracked changes into atomic commits — one commit per logical concern. A single concern is just the degenerate case: one commit. Never push — pushing belongs to /hb:to-pr.
Paths in $ARGUMENTS scope the run: commit only those files and leave the rest of the tree as it is.
Message style
Match the repo's existing commit patterns from git log. Extreme concision — sacrifice grammar for brevity. Focus on "why" not "what". Imperative mood. Conventional commits (feat/fix/refactor/docs/chore + scope) when the repo uses them.
Workflow
- Review full diff and status; read recent log for style.
- Identify logical groups: feature/fix, its tests, config, formatting-only, docs, assets.
- Per group: stage those files explicitly by name, commit with a HEREDOC message, confirm
git statusbefore the next group. - Finish with a clean working tree (scoped run: every listed file committed). Unsure how to group a file → ask.
Grouping rules
- Formatting-only changes (whitespace, quotes, indentation) get their own commit, separate from logic.
- A file with both logic and formatting changes stays in the logic commit.
- Tests and the code they test can share a commit.
- Pre-commit hook fails → fix, re-stage, create a new commit; never
--amend, never skip hooks.
Use this skill
Connect your agent to the Skill Store MCP server and ask for it by ref: helderberto/commit-718445567.
Details
- Publisher
- helderberto
- Category
- Software Development › Source control & code review
- License
- MIT
- Updated
- 2026-10-16
References
More from helderberto
- A11Y Audit Audit accessibility (WCAG) in frontend code.
- Architecture Audit Surface architectural friction across a codebase and propose deep-module refactors as RFCs.
- Build Implement the next unblocked ticket test-first and commit it, or fan every ticket out to parallel…
- Check Validate code quality — auto-fix formatting/lint, verify types, run tests.