Skill Store 33

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

  1. Review full diff and status; read recent log for style.
  2. Identify logical groups: feature/fix, its tests, config, formatting-only, docs, assets.
  3. Per group: stage those files explicitly by name, commit with a HEREDOC message, confirm git status before the next group.
  4. 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.

Download SKILL.md · Markdown version

Details

Publisher
helderberto
Category
Software Development › Source control & code review
License
MIT
Updated
2026-10-16

References

More from helderberto