Use when creating git commits, amending commits, or reviewing commit messages. Triggers on phrases like "commit my changes", "commit this", "commit what I have", "commit the staged changes", "make a commit", "save this as a commit", "create a commit", or any request to commit staged work. Also triggers via /m:commit command. Defines commit message standards: imperative verbs, 50-character limit, conventional commit prefixes adapted to the project's existing style, and absolutely no AI or tool attribution.
From mnpx claudepluginhub molcajeteai/plugin --plugin mThis skill uses the workspace's default tool permissions.
references/examples.mdreferences/message-format.mdSearches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Creates persona-targeted CodeTour .tour files with real file and line anchors for onboarding, architecture, PR, RCA tours, and structured explanations.
Standards for writing clear, concise git commit messages that communicate changes effectively.
<Verb> <what changed>
- <why detail 1>
- <why detail 2>
- <why detail 3>
The first line is the subject. The body (bullet points) is optional but recommended for non-trivial changes. Separate the subject from the body with a blank line.
Start with an imperative verb (capitalize the first letter):
Maximum 50 characters for the first line. If it exceeds 50 characters, it is too long — move details to the body.
Describe what changed, not what was wrong:
Use simple language — Avoid jargon when plain words work:
Conventional commit prefixes (feat:, fix:, test:, chore:, docs:, refactor:, perf:) — Use the appropriate prefix based on the staged changes. Check git log --oneline -20 to adapt to the project's style — if the history does not use prefixes, skip them and use the verb-only format instead.
feat: Add user dashboardAdds user dashboardUse bullet points (hyphens, not paragraphs) to explain why when:
Refactors authentication flow
- Separates login and registration logic
- Makes code easier to test independently
- Removes duplicate token validation
- Prepares for OAuth integration
For simple, obvious changes, a single subject line is enough:
Fixes typo in README
Updates dependencies to latest versions
Place issue references at the end of the subject line in parentheses:
Fixes payment processing error (#123)
Do not use issue tracker language as the subject — "Resolves #123" says nothing about what changed.
See references/message-format.md for detailed format rules. See references/examples.md for good and bad examples.
THIS IS MANDATORY — NO EXCEPTIONS.
When creating commit messages:
Commits must look like normal human development:
Focus on what changed, not how it was produced. The process of creating code is irrelevant to the commit message. Only describe the change itself.
Each commit represents one logical change:
Do not mix unrelated changes:
Small, frequent commits are better than large, infrequent ones: easier to review, easier to revert if needed, better git history, clearer project progression.
Use git diff --staged to check:
console.log, print statements)Only stage files related to the change:
# GOOD: Stage specific files
git add src/auth.js tests/auth.test.js
# AVOID: Staging everything blindly
git add .
Do not commit: API keys, passwords, private keys, access tokens, .env files with secrets.
Remove before committing: console.log() statements, commented-out code blocks, temporary test data, debug flags.
Commit messages should help understand the change months from now:
Good commit history makes git log --oneline a useful project timeline:
a1b2c3d Adds user authentication
b2c3d4e Fixes login redirect
c3d4e5f Updates password validation
d4e5f6g Refactors token handling
git-filter-repo to remove from historygit reset HEAD~1 # Undo commit, keep changes
git stash # Stash changes
git checkout correct-branch
git stash pop # Apply changes
git add .
git commit
Use git commit --amend only for minor corrections to the last commit:
git log -1 --format='%an %ae' that the commit is yours before amending.This workflow runs when the user asks to commit (natural language or /m:commit).
NEVER STAGE FILES. Do not run git add, git reset, or git restore --staged. Only commit what is already staged. If nothing is staged, stop with an error.
NEVER ADD AI ATTRIBUTION. No "Generated with Claude Code", no "Co-Authored-By: Claude", no AI emoji, no tool mentions. Commits must look like normal human development.
USE AskUserQuestion FOR ALL CONFIRMATIONS. Never ask questions as plain text. Never end your response with a question. The only way to ask for confirmation is the AskUserQuestion tool.
Run git diff --staged --stat using Bash.
If no staged changes exist, show this error and stop:
No staged changes found.
Stage your changes first:
git add <files>
Do not offer to stage files. Do not run git add. Stop immediately.
Run these three commands in parallel and store the output for later steps:
git diff --staged --stat → store as DIFF_STATgit diff --staged → store as DIFFgit log --oneline -10 → store as RECENT_LOGUse DIFF_STAT and DIFF to understand the scope of the staged changes.
A commit is too large when the staged changes contain 2 or more logically independent concerns. Examples:
Related changes are NOT too large. A version bump + changelog + the feature it describes = one logical unit. Multiple files touched by one feature = one logical unit. Judge by intent, not by file count.
If the changes represent a single logical concern, proceed to Step 3 (single commit flow).
If the changes contain multiple independent concerns, proceed to Step 2b (split flow).
Use AskUserQuestion:
If the user chooses to commit everything together, proceed to Step 3 (single commit flow).
If the user chooses to split, proceed to Step 2c.
Launch a Task with subagent_type="general-purpose". Pass DIFF_STAT, DIFF, and RECENT_LOG inline — the sub-agent must NOT run git commands or read files:
Plan how to split these staged changes into logical, atomic commits.
## Commit message rules
- Start with imperative verb: Adds, Fixes, Updates, Removes, Refactors, Improves, Moves, Renames, Replaces, Simplifies
- First line max 50 characters — move details to body bullets
- Body bullets (hyphens) explain WHY, only for non-trivial changes
- Match project prefix convention from the recent log below
- NEVER mention AI, Claude, or tools
## File summary
{DIFF_STAT}
## Full diff
{DIFF}
## Recent commits (match style)
{RECENT_LOG}
Group the changes into logical, atomic commits. Each commit = one concern.
Return a JSON array of commit groups:
- "message": the commit message
- "files": array of file paths for this commit
- "reason": one sentence explaining why these files belong together
Example:
[
{"message": "Adds user search endpoint\n\n- Adds GET /users/search with query parameter\n- Includes pagination support", "files": ["src/routes/users.ts", "src/services/search.ts", "tests/routes/users.test.ts"], "reason": "All files implement the search feature"},
{"message": "Fixes typo in README", "files": ["README.md"], "reason": "Unrelated documentation fix"}
]
Return ONLY the JSON array, nothing else.
Before starting the loop:
git diff --staged --name-only and store the list as ORIGINALLY_STAGED.git reset HEAD -- . to clear the staging area. This does not touch the working tree -- all changes remain as unstaged modifications.For each commit group, in order:
git add {files}\n{message}\n\n\nFiles: {file list}"/tmp/claude/commit-msg.txt and run git commit -F /tmp/claude/commit-msg.txt && rm /tmp/claude/commit-msg.txt && git log --oneline -1git reset HEAD -- {files} to unstage this group's files back to the working tree, then continue to next group.After all groups are processed:
git add {skipped files}.ORIGINALLY_STAGED are never touched -- they remain as unstaged working tree changes throughout.Report all commits created (hash + message for each).
Draft the commit message directly — do NOT launch a sub-agent. You already have DIFF_STAT, DIFF, and RECENT_LOG in context from Step 2. Use the commit message rules from this skill (imperative verb, 50-char limit, body bullets for non-trivial changes, match project prefix convention from RECENT_LOG, no AI attribution).
Use AskUserQuestion with the drafted message:
\n{drafted message}\n"If the user types in Other or selects "Edit message":
After confirmation, write the commit message file using the Write tool, then commit using Bash. Do NOT use heredocs -- zsh's internal heredoc temp file creation is blocked by the sandbox.
/tmp/claude/commit-msg.txt with the confirmed messagegit commit -F /tmp/claude/commit-msg.txt && rm /tmp/claude/commit-msg.txt && git log --oneline -1
Report the result: show the commit hash and message.
ORIGINALLY_STAGED. Never touch files that were not originally staged.ORIGINALLY_STAGED so the user's staging area is restored, then stop and report the error.| File | Description |
|---|---|
| references/message-format.md | Detailed commit message format rules, verb list, body guidelines |
| references/examples.md | Good and bad commit message examples for common scenarios |