Back to skills
devv1.0.0Free

Commit Message

Generate a Conventional Commits message from a git diff. Use when the user pastes a diff, says "commit this", or asks "what is a good commit message for this?". Picks the right type/scope, writes an imperative subject under 72 chars, and adds a body only when the change needs one.

Activate this skill on your agent
Adds commit-message to your agent’s instructions. The skill takes effect on your next provision or refresh.
Sign up to activate →
SKILL.md
# Commit Message

Generate a Conventional Commits message from a git diff.

## When to use

Use this skill when the user:
- Pastes a diff (`git diff`, `git diff --cached`, or a unified diff blob)
- Asks "what's a good commit message for this?"
- Says "commit this for me"
- Provides a list of file changes and asks for a message

If git tools are available, you may run `git diff --cached` yourself when
the user says "commit my staged changes".

## Inputs

A git diff. Either:
- Pasted text (unified diff format)
- Output of `git diff --cached` or `git status -s` + `git diff <files>`
- A description of changes if no diff is available (less ideal)

Optional:
- `scope` hint — e.g. "auth", "billing"
- `type` override — e.g. "force this to be a refactor"

## Output format

A single Conventional Commits message:

```
<type>(<scope>): <subject>

<body>

<footer>
```

Rules:
- **type**: one of `feat`, `fix`, `docs`, `style`, `refactor`, `perf`,
  `test`, `build`, `ci`, `chore`, `revert`.
- **scope** (optional): lowercase, single word, derived from changed paths.
  Examples: `auth`, `api`, `db`, `ui`. Skip if changes span >2 unrelated areas.
- **subject**: imperative mood ("add", not "added" or "adds"), no period,
  ≤ 72 chars total including the type prefix.
- **body** (optional): wrap at 72 cols. Explain *why*, not *what* — the diff
  shows *what*. Skip if the subject is self-explanatory.
- **footer** (optional): `BREAKING CHANGE: <description>` if behavior breaks,
  or `Fixes: #123` / `Refs: #456` if the user mentioned an issue.

## Process

1. Read the diff. Identify primary intent: new feature, bug fix, refactor,
   or chore.
2. Pick the dominant type. If multiple types apply, prefer the one that
   would matter to a user reading the changelog.
3. Pick scope from the most-touched directory: `lib/auth/*` → scope `auth`.
4. Write the subject in <72 chars, imperative.
5. Decide if a body is needed:
   - Yes if the diff is non-obvious, fixes a subtle bug, or has tradeoffs.
   - No if it's a one-line typo fix or doc tweak.
6. Add `BREAKING CHANGE:` footer ONLY when an exported API signature, env
   var, or DB schema changes in a non-additive way.

## Examples

**Diff shows:** A new `POST /api/skills/import` route + tests.
```
feat(skills): add import endpoint with raw/url/github sources

Accepts SKILL.md content via three source kinds and persists to
skill_definitions + skill_versions in a single transaction. Rate-limited
to 30 imports per user per hour.
```

**Diff shows:** Off-by-one in pagination.
```
fix(api): include final page in /users list pagination

Loop bound was strict-less-than instead of less-than-or-equal, so the
last page was silently dropped when total_count was an exact multiple
of page_size.
```

**Diff shows:** A schema column added with a default.
```
feat(db): add user.last_seen_at column
```

## Hard rules

- One commit, one logical change. If the diff spans truly unrelated areas,
  recommend splitting and explain why.
- Never use "update", "improve", "fix stuff", "various changes" — these are
  banned.
- Never end the subject with a period.
- Never exceed 72 chars on any line.