GIT Commit Writer
Trigger when the user asks to write a commit message, generate a commit from staged...
Install
npx skills add mergisi/awesome-openclaw-agents --skill git-commit-writer -g -a claude-code -y- Repository
- mergisi/awesome-openclaw-agents4k
- Category
- Git and review
- Updated
- 7d ago
- License
- MIT
- Context cost
- Lightabout 594 tokens
- Runs scripts
- No, instructions only
What it does
Trigger when the user asks to write a commit message, generate a commit from staged changes, review a diff before committing, or says "/commit". Reads git diff --staged and produces an opinionated, convention-matching commit message.
Git Commit Writer
Generate a disciplined commit message from the currently staged changes. Opinionated about style: imperative mood, concise title, body that explains why not what.
When to use
- User says "write a commit message", "/commit", "commit this"
- User has staged changes and asks to review them before committing
- User asks "what should this commit be called"
Do NOT use this skill to actually run git commit unless the user explicitly asks, just draft the message and show it.
Instructions
- Run
git status --shortwith the Bash tool. Confirm there are staged changes. If nothing is staged, stop and tell the user. - Run
git diff --stagedto read the full staged diff. If the diff is large (>500 lines), also rungit diff --staged --statto get a file-level overview first. - Run
git log --oneline -10to learn the repo's commit convention. Look for:- Conventional Commits prefixes (
feat:,fix:,chore:), if present, match the style. - Title case vs sentence case.
- Whether bodies are used or not.
- Any ticket / issue prefix (e.g.
[PROJ-123]).
- Conventional Commits prefixes (
- Draft a message following these rules:
- Title: imperative mood ("Add X", not "Added X" or "Adds X"), max 70 characters, no trailing period.
- Body (if needed): blank line after title, then 1-3 short paragraphs or bullets explaining why the change is necessary, what problem it solves, what trade-offs were made.
- Never use the word "refactor" alone, always say what was refactored and why ("Extract retry loop into helper to share with job runner").
- Never write "Update file.js", describe the behavior change, not the file touched.
- Never invent a ticket number. If the repo uses them but you can't infer one, leave it out.
- Show the drafted message in a fenced code block. Ask the user if they want you to run
git commitwith it. Do not commit automatically.

