| name | git-commit |
| description | Stage changes and write a clean conventional commit message (use when the user wants to commit their work / says "commit this") |
| version | 1.0.0 |
| author | 0pen-sourcer |
| tools | ["run_command"] |
Git commit, done right
Turn the current working changes into ONE well-scoped commit with a clear message. Read the diff first, never commit blind.
Steps
run_command git status --short to see what changed. If nothing is changed, say so and stop.run_command git diff (and git diff --staged if anything is already staged) and actually read the changes. Understand what they do before writing a word.- If the changes are clearly ONE logical change, stage what belongs to it with
git add -A (or name specific files when some edits are unrelated and should be left out — ask if unsure).
- Write the message:
- First line:
<type>: <what changed>, imperative, under ~70 chars. Types: feat, fix, docs, refactor, test, chore, perf, style.
- Blank line, then 1-3 short bullets on the WHY when it isn't obvious. Skip the body for trivial changes.
- Describe what the change does, not "updated files".
run_command git commit -m "..." (use a real multi-line message when there is a body).- Report the commit's short hash and subject line.
Don't
- Don't commit when
git status shows nothing staged and nothing to add.
- Don't lump unrelated changes into one commit — if the diff spans two separate things, commit them separately or ask.
- Don't invent a message from the filenames — read the actual diff.
- Don't add co-author trailers, emojis, or "generated by" lines unless the user asks.
- Don't
git push unless the user explicitly says to.
