How do I install the Commit Message skill?

Run npx skillmds@latest add gabriel-f-santos/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?

gabriel-f-santos (@gabriel-f-santos) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Commit Message by gabriel-f-santos — Agent Skill

Name: Commit Message
Author: gabriel-f-santos

Commit Message

Generate a Conventional Commits message from staged changes. Use when the user asks to "write a commit message", "commit message", "gera a mensagem de commit", "commita isso", or right after staging with git add. Reads the staged diff, classifies it (feat/fix/docs/refactor/test/chore/...), and writes a <72-char imperative subject plus an optional body — it presents the message, it does not run the commit. Do not use for PR descriptions or changelogs — those are separate concerns.

gabriel-f-santos 6d0f190 3 files · 4.9 KB Updated Sep 17, 2026

File contents

commit-message — Conventional Commits from staged changes

Turn the staged diff into a clean Conventional Commits message. The skill reads and drafts — it never commits. The user reviews and commits themselves.

Process

Read the staged changes. Run git diff --staged --stat for the shape and git diff --staged for the content. If nothing is staged, run git status and tell the user to git add first — don't invent a diff.
Match the repo's style. Run git log -5 --pretty=%s and follow the existing convention (scope usage, language, capitalization) when it doesn't conflict with the rules below.
Classify the change against the type table. One commit = one logical change; if the diff mixes unrelated changes, say so and suggest splitting.
Draft subject + optional body using the output template.
Self-check against the checklist, fix violations, then present the message in a fenced block for the user to copy. Do not execute the commit.

Conventional Commits types

Type	Use for
`feat`	a new user-facing feature
`fix`	a bug fix
`docs`	documentation only
`refactor`	behavior-preserving code change
`perf`	performance improvement
`test`	adding/adjusting tests
`build`	build system or dependencies
`ci`	CI configuration
`chore`	maintenance, no src/test change
`style`	formatting only (whitespace, semicolons)

Add a scope in parentheses when it sharpens meaning: feat(auth): …. Append ! (or a BREAKING CHANGE: footer) for breaking changes: feat(api)!: ….

Output template

<type>(<scope>): <imperative subject, ≤72 chars, no trailing period>

<optional body: what & why, wrapped at ~72 cols. Blank line above.>

<optional footer: BREAKING CHANGE: …  /  Refs: #123>

Example Input (staged): added JWT verification middleware + a test Output:

feat(auth): verify JWT on protected routes

Add middleware that validates the bearer token and rejects expired or
malformed tokens with 401 before the handler runs.

Self-check (run before presenting)

Subject ≤ 72 characters
Imperative mood ("add", not "added"/"adds")
No trailing period on the subject
Type is from the table and matches the actual change
Subject describes the change, not the file ("add retry to fetch", not "edit fetch.ts")
Body present when the why isn't obvious from the subject; omitted when trivial
One logical change — flagged the user if the diff mixes concerns

---name: commit-messagedescription: Generate a Conventional Commits message from staged changes. Use when the user asks to "write a commit message", "commit message", "gera a mensagem de commit", "commita isso", or right after staging with git add. Reads the staged diff, classifies it (feat/fix/docs/refactor/test/chore/...), and writes a <72-char imperative subject plus an optional body — it presents the message, it does not run the commit. Do not use for PR descriptions or changelogs — those are separate concerns.---# commit-message — Conventional Commits from staged changesTurn the staged diff into a clean Conventional Commits message. The skill **reads and drafts**— it never commits. The user reviews and commits themselves.## Process1. **Read the staged changes.** Run `git diff --staged --stat` for the shape and `git diff --staged` for the content. If nothing is staged, run `git status` and tell the user to `git add` first — don't invent a diff.2. **Match the repo's style.** Run `git log -5 --pretty=%s` and follow the existing convention (scope usage, language, capitalization) when it doesn't conflict with the rules below.3. **Classify the change** against the type table. One commit = one logical change; if the diff mixes unrelated changes, say so and suggest splitting.4. **Draft** subject + optional body using the output template.5. **Self-check** against the checklist, fix violations, then present the message in a fenced block for the user to copy. Do not execute the commit.## Conventional Commits types| Type | Use for ||---|---|| `feat` | a new user-facing feature || `fix` | a bug fix || `docs` | documentation only || `refactor` | behavior-preserving code change || `perf` | performance improvement || `test` | adding/adjusting tests || `build` | build system or dependencies || `ci` | CI configuration || `chore` | maintenance, no src/test change || `style` | formatting only (whitespace, semicolons) |Add a scope in parentheses when it sharpens meaning: `feat(auth): …`. Append `!` (or a`BREAKING CHANGE:` footer) for breaking changes: `feat(api)!: …`.## Output template```<type>(<scope>): <imperative subject, ≤72 chars, no trailing period><optional body: what & why, wrapped at ~72 cols. Blank line above.><optional footer: BREAKING CHANGE: … / Refs: #123>```**Example**Input (staged): added JWT verification middleware + a testOutput:```feat(auth): verify JWT on protected routesAdd middleware that validates the bearer token and rejects expired ormalformed tokens with 401 before the handler runs.```## Self-check (run before presenting)- [ ] Subject ≤ 72 characters- [ ] Imperative mood ("add", not "added"/"adds")- [ ] No trailing period on the subject- [ ] Type is from the table and matches the actual change- [ ] Subject describes the change, not the file ("add retry to fetch", not "edit fetch.ts")- [ ] Body present when the *why* isn't obvious from the subject; omitted when trivial- [ ] One logical change — flagged the user if the diff mixes concerns

Frequently asked questions