Generates a tight, conventional commit message from a staged diff — accurate verb, no fluff, no co-authors line.

git
commit-message
engineering
claude
cursor
codex

Resource content

This is the actual file you get when you install — read it here, or copy it to use anywhere.

skill.md

Commit Message Helper

Generate one commit message from the provided diff. Optimize for being scannable in git log --oneline and useful to a future debugger.

Input

A unified diff (or a description of changes). May span many files.

Process

Identify the one thing this commit accomplishes. State it as a verb phrase: "add X", "fix Y", "remove Z", "refactor W". If there are multiple things, the commit is too big — say so explicitly and suggest a split before producing a message.
Pick the verb carefully:
- add — wholly new feature, file, or behavior that did not exist before
- fix — corrects an existing bug (state the bug, briefly)
- update — modifies existing behavior without removing it
- remove — deletes something
- refactor — restructures code without changing observable behavior
- rename — file/symbol rename only
- bump / upgrade — dependency or version change
- revert — undoing a prior commit
- test — only adds or changes tests
- docs — only changes documentation
- chore — meta tasks (configs, CI, scripts) with no user-facing change
Do not use update or improve as escape hatches for "I don't know what changed."
The subject line:
- One line, ≤ 72 chars
- Imperative, present tense ("Add", not "Added" or "Adds")
- No trailing period
- No prefix unless the project uses one consistently (don't invent feat: if the project doesn't use Conventional Commits)
- Mentions the user-facing surface affected ("Add --quiet flag to undra-cli", not "Modify cli.rs")
The body (optional — only if the subject line can't tell the whole story):
- Wrap at 72 chars
- Explain why, not what (the diff already shows what)
- Reference issues by number when relevant: Closes #123
- 2–4 sentences max

Output format

<subject>

<body if needed>

Just the message. No explanation, no preamble, no "Here's a commit message:" framing.

Anti-patterns to avoid

update files (says nothing)
WIP / temp (not a real commit message — squash before merging)
fix bug without saying which bug
Marketing language: "improve", "enhance", "make better"
Comma-separated subject lines that smuggle in multiple commits
Auto-generated co-author trailers unless the user explicitly asks for them

---
name: commit-message-helper
description: Generate a tight conventional commit message from a staged git diff. Use when the user asks for a "commit message", says "what should I name this commit", or pastes a diff for review.
---

# Commit Message Helper

Generate one commit message from the provided diff. Optimize for being scannable in `git log --oneline` and useful to a future debugger.

## Input

A unified diff (or a description of changes). May span many files.

## Process

1. Identify **the one thing this commit accomplishes**. State it as a verb phrase: "add X", "fix Y", "remove Z", "refactor W". If there are multiple things, the commit is too big — say so explicitly and suggest a split before producing a message.

2. Pick the verb carefully:
   - `add` — wholly new feature, file, or behavior that did not exist before
   - `fix` — corrects an existing bug (state the bug, briefly)
   - `update` — modifies existing behavior without removing it
   - `remove` — deletes something
   - `refactor` — restructures code without changing observable behavior
   - `rename` — file/symbol rename only
   - `bump` / `upgrade` — dependency or version change
   - `revert` — undoing a prior commit
   - `test` — only adds or changes tests
   - `docs` — only changes documentation
   - `chore` — meta tasks (configs, CI, scripts) with no user-facing change

   Do not use `update` or `improve` as escape hatches for "I don't know what changed."

3. The subject line:
   - One line, ≤ 72 chars
   - Imperative, present tense ("Add", not "Added" or "Adds")
   - No trailing period
   - No prefix unless the project uses one consistently (don't invent `feat:` if the project doesn't use Conventional Commits)
   - Mentions the user-facing surface affected ("Add `--quiet` flag to `undra-cli`", not "Modify cli.rs")

4. The body (optional — only if the subject line can't tell the whole story):
   - Wrap at 72 chars
   - Explain *why*, not *what* (the diff already shows what)
   - Reference issues by number when relevant: `Closes #123`
   - 2–4 sentences max

## Output format

```
<subject>

<body if needed>
```

Just the message. No explanation, no preamble, no "Here's a commit message:" framing.

## Anti-patterns to avoid

- `update files` (says nothing)
- `WIP` / `temp` (not a real commit message — squash before merging)
- `fix bug` without saying which bug
- Marketing language: "improve", "enhance", "make better"
- Comma-separated subject lines that smuggle in multiple commits
- Auto-generated co-author trailers unless the user explicitly asks for them

How to use this

Undra: One-click install. The skill writes to <workspace>/.undra/ai/skills/<id>/SKILL.md and the AI assistant picks it up automatically.
Claude (claude.ai or Claude Code): Save the file as SKILL.md inside ~/.claude/skills/<skill-name>/. Restart Claude. The skill becomes available.
Cursor / Codex / any model with a system prompt: Paste the body of the file into a Cursor rule, a Codex prompt, or the system prompt of any chat. Skip the frontmatter.