| name | commit |
| description | Create focused, atomic git commits following Conventional Commits v1.0.0. Each commit is a single logical change with a rationale body explaining why. Use when the user says "commit", "make a commit", or wants to commit changes. |
| user-invocable | true |
| disable-model-invocation | false |
| allowed-tools | ["Bash","Read","Grep","Glob"] |
/commit — Focused Conventional Commits
Create focused, independent VCS commits that follow
Conventional Commits v1.0.0.
Every commit body serves as a durable decision record explaining why changes
were made, so humans and LLMs reviewing history can understand rationale.
Workflow
-
Inspect the working tree. Run git status (never -uall) and
git diff (staged + unstaged). Read recent git log --format='%B---' -5
to stay consistent with existing style and scope conventions.
-
Partition into atomic units. Each commit must be a single, self-contained
logical change. If the working tree contains multiple independent changes,
split them into separate commits automatically — one per logical unit.
A commit is atomic when it answers exactly one "why."
-
Stage precisely. Use git add <path>… for each commit — never
git add -A or git add .. Never stage files that look like secrets
(.env, credentials.*, tokens, private keys). Warn the user and refuse
if detected.
-
Write the commit message using the format below.
-
Verify. Run git status after each commit to confirm success.
Commit Message Format
<type>(<scope>): <subject>
<body>
[<footer(s)>]
Subject Line
| Field | Rules |
|---|
<type> | One of: feat, fix, refactor, perf, test, docs, style, build, ci, chore, revert |
<scope> | Always required. Use the narrowest accurate scope for the change. Freeform — match the project's existing scope conventions when present. For cross-cutting changes, use repo. |
<subject> | Imperative mood, lowercase, no period, 50 chars max. Describe what changed. |
| Breaking | Append ! after scope: feat(api)!: remove legacy endpoint and add a BREAKING CHANGE: footer. |
Body
The body is a micro decision record. It answers why, not what — the
diff shows what. Write it so a developer or an LLM summarizing history can
understand the motivation without reading the code.
Structure as concise prose following this pattern:
- Problem or motivation — what prompted the change
- Approach chosen — why this solution over alternatives
- Tradeoffs accepted — what was given up, if anything
Keep it to 1-4 wrapped lines. Hard-wrap at 72 characters. Use plain prose
with causal connectives ("because", "instead of", "despite"), not bullet
lists — structured prose is easier for LLMs to summarize.
Trivial opt-out: A body may be omitted only when ALL of these hold:
the subject fully communicates intent, the diff is self-explanatory, and
there is no non-obvious motivation. Examples: typo fixes, single dependency
additions with obvious purpose, version bumps.
When in doubt, include a body.
Footers
Use git-trailer format.
Only include footers when applicable — no AI attribution trailers.
| Trailer | When |
|---|
BREAKING CHANGE: <description> | Required for any breaking change. |
Refs: <issue or URL> | When related to a tracked issue. |
Example
feat(auth): replace session tokens with JWT
Cookie-based sessions required server-side state that complicated
horizontal scaling. JWTs are stateless and let each service verify
independently, at the cost of slightly larger payloads and no
server-side revocation without a denylist.
Multi-Commit Behavior
When the working tree contains multiple independent changes, split them
into separate atomic commits automatically without asking for confirmation.
Apply these heuristics:
- Changes to different subsystems (different scopes) are independent
- A refactoring prerequisite goes in its own commit before the feature commit
- Formatting/style changes are separate from behavioral changes
- Each commit must leave the repo in a valid state
Hook Failure Handling
If a pre-commit hook fails:
- Never use
--amend — the commit did not happen, so amending would
modify the previous unrelated commit.
- Identify what the hook caught and explain it to the user.
- Fix the issue and re-stage the affected files.
- Create a new commit with the original message.
Passing the Message to Git
Always use a heredoc to preserve formatting:
git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>
<body>
<footer(s)>
EOF
)"
Prohibitions
- Never
git push unless the user explicitly asks.
- Never
--no-verify or --no-gpg-sign unless the user explicitly asks.
- Never
--amend unless the user explicitly asks.
- Never force-push to
main/master.
- Never commit secrets.
