Commit message writer
Write short, accurate Git commit messages in English. Use when the user asks to commit, create a PR, or write a commit message. ALWAYS check the actual git diff first. ALWAYS write the commit message in English regardless of what language the user speaks.From its SKILL.md
npx -y skills add bilals2008/bilal-skills --skill commit-message-writerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.4 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
Commit Message Writer
Purpose
Write concise, accurate Git commit messages based on real file changes. Never fabricate. Never write long paragraphs.
Instructions
Step 1 — Read actual changes FIRST
Run this command immediately:
git diff --staged
If nothing is staged:
git diff
If still nothing:
git log --oneline -5
Step 2 — Analyze changes
Look at:
- Which files changed
- What actually changed (added, removed, modified)
- The real diff content
NEVER guess or fabricate changes. Only write what you actually see in the diff.
Step 3 — Group changes wisely (1-2 commits preferred)
Check git diff --name-only or git diff --staged --name-only.
First try to fit into 1-2 commits. If all changes are related (e.g., all in the same feature or all are small fixes), one commit is better than 4 unnecessary splits.
Split only when changes are clearly unrelated:
- A new feature AND a docs update AND a dependency change → 2-3 commits max
- All files in same component/feature → 1 commit
| Group | Example files | Type |
|---|---|---|
| New feature files | feat-*.ts, api/*.ts | feat |
| Bug fixes | fix-*.ts | fix |
| Styling/CSS | *.css, *.scss, tailwind classes | style |
| Refactoring | files where only structure changed | refactor |
| Config/build | package.json, .gitignore, configs | chore |
| Docs | *.md, README, comments | docs |
Decision guide:
- All files in same feature/component? → 1 commit
- One feature + some styling? → 1 commit (feat: add feature and update styles)
- Feature + docs + package change? → 2-3 commits max
- Only 2-4 files? → 1 commit usually enough
- Many files with clearly different concerns? → 2-3 commits max
How to execute:
- Decide groups (aim for 1-2, max 3)
- Show plan to user
- Wait for approval
- If user says "commit everything together", one commit for everything
Example: If git diff --name-only shows:
src/api/login.ts
src/api/logout.ts
src/styles/button.css
src/styles/form.css
README.md
package.json
Then propose 4 commits:
feat(api): add login and logout endpoints
style: update button and form styling
docs: update readme
chore: update package.json
Step 4 — Write each commit message
Use this format (Conventional Commits):
<type>(<scope>): <short description>
| Type | When to use |
|---|---|
feat | New feature |
fix | Bug fix |
refactor | Code change without fix/feature |
style | Formatting, CSS |
docs | Documentation |
chore | Build, deps, config |
perf | Performance improvement |
Rules:
- Short description: max 10 words, no period at end
- Body (optional): max 2 lines, each line under 72 chars
- ALWAYS write the commit message in English — regardless of what language the user speaks (Urdu, Hindi, Chinese, Spanish, Arabic, etc.)
- One logical change = one commit. Don't bundle unrelated changes together
Step 5 — Show user before committing
Show the plan (splits + messages) and wait for approval before running git commit.
Examples
User says:
"I changed the button color and removed extra spacing"
You write:
style(button): update color and remove extra spacing
User says:
"commit everything"
You check diff, find files:
src/auth/login.ts
src/auth/register.ts
src/styles/button.css
README.md
Propose:
1. feat(auth): add login and register pages
2. style: update button styling
3. docs: update readme
User says:
"commit all changes"
You check diff, then:
refactor(api): clean up unused endpoints
What NOT to do
- Long commit messages like "This commit adds a new feature for the login functionality which include..."
- Fabricating changes you didn't see in the diff
- Writing commit messages in any language other than English
- Writing "fix: fix some issues" — be specific about what was fixed
- Writing commit for files that haven't changed
Expected Output
type(scope): short description (max 10 words)
Optional body (max 2 lines)
Always English. Always accurate. Always short.
What ships with it: 1 file
504 B alongside SKILL.md, 1 of them executable
scripts/
- get-diff-summary.ps1runs504 B