How do I install the Commit Message skill?

Run npx skillmds@latest add rokurokulab/commit-message in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Commit Message safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Commit Message?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Commit Message free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Commit Message?

rokurokulab (@rokurokulab) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Commit Message by rokurokulab — Agent Skill

Name: Commit Message
Author: rokurokulab

Commit Message

Generate a Conventional Commits message from staged or unstaged changes. Use when the user asks for a commit message, says "commit this", or wants help writing the subject/body for changes already in the working tree.

rokurokulab 3b18400 2.2 KB Updated Sep 17, 2026

File contents

commit-message

Produce a clean, Conventional Commits-formatted message that matches the repo's house style.

When to invoke

User asks "write a commit message", "what should I commit this as?", "commit this for me"
User stages changes and asks for help wording them
Don't invoke for git status summaries — that's not a commit message request

What to do

Read the change, in this priority order:
- git diff --cached (staged) if non-empty → use this
- git diff (unstaged) if no staged changes
- Specific files the user named
Skim the last 10 commits with git log --oneline -10 to learn the project's tone (scope conventions, voice, length).
Pick a type: feat, fix, docs, chore, refactor, test, style, perf, ci, build, revert. When in doubt:
- New behavior → feat
- Restoring intended behavior → fix
- No behavior change, code shape only → refactor
- Test-only → test
- CI/CD → ci
Pick a scope (optional) only if it adds clarity: feat(api):, fix(auth):. Don't manufacture scopes for cosmetic consistency.
Write the subject: ≤72 chars, imperative mood, no trailing period. "Add retry on 5xx" not "Added retry on 5xx".
Write a body (only if needed) explaining why the change is needed — not what (the diff shows that). Reference issue/PR numbers if available. Wrap at 72 cols.
Mark breaking changes with BREAKING CHANGE: footer or ! after type: feat(api)!: drop /v1 endpoint.

Output format

Print the message in a fenced block ready to paste:

feat(api): add retry on 5xx responses

Upstream service is occasionally flaky during deploys; retrying with
exponential backoff cuts our error rate by ~60% during deploy windows.
Capped at 3 attempts to avoid amplifying real outages.

Refs: #1234

If multiple distinct changes are mixed in the diff, say so and propose splitting them rather than producing one Frankenstein commit.

---name: commit-messagedescription: Generate a Conventional Commits message from staged or unstaged changes. Use when the user asks for a commit message, says "commit this", or wants help writing the subject/body for changes already in the working tree.---# commit-messageProduce a clean, [Conventional Commits](https://www.conventionalcommits.org/)-formatted message that matches the repo's house style.## When to invoke- User asks "write a commit message", "what should I commit this as?", "commit this for me"- User stages changes and asks for help wording them- Don't invoke for `git status` summaries — that's not a commit message request## What to do1. **Read the change**, in this priority order: - `git diff --cached` (staged) if non-empty → use this - `git diff` (unstaged) if no staged changes - Specific files the user named2. **Skim the last 10 commits** with `git log --oneline -10` to learn the project's tone (scope conventions, voice, length).3. **Pick a type**: `feat`, `fix`, `docs`, `chore`, `refactor`, `test`, `style`, `perf`, `ci`, `build`, `revert`. When in doubt: - New behavior → `feat` - Restoring intended behavior → `fix` - No behavior change, code shape only → `refactor` - Test-only → `test` - CI/CD → `ci`4. **Pick a scope** (optional) only if it adds clarity: `feat(api):`, `fix(auth):`. Don't manufacture scopes for cosmetic consistency.5. **Write the subject**: ≤72 chars, imperative mood, no trailing period. "Add retry on 5xx" not "Added retry on 5xx".6. **Write a body** (only if needed) explaining *why* the change is needed — not what (the diff shows that). Reference issue/PR numbers if available. Wrap at 72 cols.7. **Mark breaking changes** with `BREAKING CHANGE:` footer or `!` after type: `feat(api)!: drop /v1 endpoint`.## Output formatPrint the message in a fenced block ready to paste:```feat(api): add retry on 5xx responsesUpstream service is occasionally flaky during deploys; retrying withexponential backoff cuts our error rate by ~60% during deploy windows.Capped at 3 attempts to avoid amplifying real outages.Refs: #1234```If multiple distinct changes are mixed in the diff, **say so** and propose splitting them rather than producing one Frankenstein commit.

Frequently asked questions