Use this skill whenever the user asks to create commits directly in normal conversation, not only when they invoke /commit.
-
Commit format:
<emoji> <type>(<scope>): <summary>
Scope is optional:
<emoji> <type>: <summary>
Example: ✨ feat(auth): Add user authentication system
-
Choose the most appropriate gitmoji from the common shortlist below. If none fit well and gitmoji is installed, you may run gitmoji list for the full catalog.
-
Use one emoji per commit and one primary purpose per commit.
-
Use a conventional type such as feat, fix, docs, refactor, test, chore, or perf.
-
Keep the scope short and lowercase when used, such as git, docs, ui, deps, or agent.
-
Keep summaries concise, imperative, and without a trailing period.
-
If a commit could fit multiple categories, choose the emoji and type that best reflect the primary impact of the change rather than the implementation detail.
-
Use a body when needed to explain why the change exists, tradeoffs, issue references, or migration notes instead of repeating the diff.
-
Never put escaped newline sequences such as \n or \n\n inside quoted git commit -m arguments. Git stores those backslash sequences literally instead of turning them into blank lines.
-
For multiline commit messages, use multiple -m flags:
git commit \
-m "✨ feat(scope): Summary" \
-m "Body paragraph." \
-m "Verification: npm test" \
-m "closes #123"
Or write the message to a temporary file and pass it with -F:
cat > /tmp/commit-message.txt <<'EOF_COMMIT'
✨ feat(scope): Summary
Body paragraph.
Verification: npm test
closes
EOF_COMMIT
git commit -F /tmp/commit-message.txt
-
If the conversation explicitly ties the work to a GitHub issue (for example work on this issue https://github.com/<org>/<repo>/issues/123 or fix #123), include closes #123 in the commit body of the commit that is intended to close that issue when merged. Do not guess issue numbers.
-
Do not add sign-offs.
-
Commit during implementation when a meaningful task group or work slice is complete and verified; do not wait until the very end.
-
Use one coherent commit per meaningful task group. Do not create one commit per file or tiny checkbox, and do not batch unrelated work into one large commit.
-
Select the file list for each commit explicitly. If unrelated files are already staged, leave them out of the current commit.
-
If the changes naturally split into multiple unrelated commit groups, STOP and present the proposed split for approval before committing anything.
-
If it is unclear whether a file belongs in the commit, ask the user before staging or committing it.
-
Never use --no-verify. If a hook fails, report the failure clearly and do not bypass it.
-
Only commit. Do not push unless the user explicitly asks.
-
Never force push. Force pushing is a user-only action, even when the user asks for git workflow help; stop and ask the user to run any required force-push step manually.
-
Do not commit directly on main. This repository keeps main clean and expects work on a branch named <firstname>/<type>/<topic-more_info>.
Use the closest matching emoji from this shortlist for normal work.
Prefer the matching conventional type alongside the emoji, for example:
When a commit could fit several categories, prefer the one with the greatest impact. A useful rule of thumb is:
-
Find the target commit SHA:
git log --oneline
-
Stage the correction normally, then commit with --fixup:
git add <files>
git commit --fixup=<sha>
Git will create a commit titled fixup! <original message> automatically — no gitmoji format needed for the fixup commit itself.
To reword a commit message instead of (or in addition to) fixing content, use an amend! commit. Create it manually with --allow-empty to avoid editor complications:
git commit --allow-empty -m "amend! <exact original subject>
<new desired commit message>"
During autosquash, git squashes the empty commit and replaces the original's message with the body of the amend! commit (i.e., the new message you wrote). The amend! subject line must match the original commit's subject exactly for autosquash to locate it.
After creating the fixup! or amend! commit, stop and report what you created so the user can review it. Do not run autosquash yet unless the user explicitly asks for it now.
-
If the user explicitly asks to squash it now, run autosquash (replace <sha> with the target commit's SHA):
GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash <sha>^
GIT_SEQUENCE_EDITOR=true skips the interactive editor and accepts the autosquash plan directly. Omit it if the user wants to review the rebase plan first.
-
Verify the result:
git log --oneline
