# Commit

> Produce a copyable commit message for the latest changes (does not run git commit). Use only when the user explicitly asks for a commit message or runs /commit.

- Skill: `limonequantistico/commit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add limonequantistico/commit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/limonequantistico/commit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: limonequantistico (https://skillmd.com/u/limonequantistico)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/limonequantistico/commit

---


You are producing a **copyable commit message** for the user's latest changes. Do not run `git commit` — just output the message in a single fenced code block so the user can copy it.

**Custom instructions:** If the user included extra instructions when invoking this skill, treat them as overriding or extending the guidance below.

### 1. Figure out what changed

- First, rely on the **conversation history**. If you (or the user) made the changes earlier in this chat, you already know what was done and why — use that as the primary source.
- If the chat history doesn't cover the changes, inspect the working tree to understand the latest uncommitted changes:
  - `git status` for the file list
  - `git diff` (and `git diff --staged`) for the actual edits
- Consult `.docs/backlog.md` if it helps explain the intent behind the changes (e.g. a backlog item that was just completed).
- If the scope is still unclear after all of the above, ask the user before writing the message.

### 2. Check the commit convention

Before writing the message, make sure it matches the convention this project actually uses — don't assume Conventional Commits.

- **A recorded decision wins outright.** If `.docs/commit-convention.md` exists, follow it and skip to the next step — no re-analysis, no asking.
- **Otherwise, look at recent history**: `git log -20 --no-merges --oneline`.
  - **Too little history** (fewer than ~5 commits, e.g. a brand-new repo): default to Conventional Commits, write that default to `.docs/commit-convention.md`, and say so in one line.
  - **A dominant pattern** (Conventional Commits, a ticket/issue-ID prefix, gitmoji, plain imperative subjects with no prefix, or something else consistent across most of the sample): adopt it, write it to `.docs/commit-convention.md`, and tell the user in one line what you detected and that you're following it.
  - **Mixed or ambiguous**: ask the user once which convention to use, recommending Conventional Commits if they have no preference. Once they answer, write it to `.docs/commit-convention.md` and say plainly it's saved so you won't be asked again.
- `.docs/commit-convention.md` is shared with `/merge` and `/push` — whichever of the three runs first writes it, the others just read it.

### 3. Write the message

If `.docs/commit-convention.md` says something other than Conventional Commits, follow that format and skip the rest of this section. Otherwise, format:

```
<type>: changed this, added that, edited this, removed this

- more specific bullet about one change
- more specific bullet about another change
- ...
```

- **Title line**: follows [Conventional Commits](https://www.conventionalcommits.org/) — `<type>: <summary>`, where type is one of `feat`, `fix`, `docs`, `refactor`, `chore`, `style`, `test`, `perf`, `build`, `ci`. Then a short comma-separated list of the main changes using plain verbs (`added`, `changed`, `removed`, `edited`, `fixed`). Keep it under ~100 characters when reasonable.
- **Breaking changes**: mark them, either with `!` after the type (`feat!: ...`) or a `BREAKING CHANGE:` line in the body. This is the one detail that must not be skipped — it's what decides a major version.
- **Body**: a blank line, then bullet points going a bit deeper — one bullet per meaningful change. Keep each bullet short and concrete. Don't pad with obvious filler.
- Pick the `<type>` that best matches the dominant change. If truly mixed, `chore` or `refactor` are fine.

- Describe the "what" plainly. Only include a "why" if it's non-obvious and useful.
- Do **not** add footers, Co-Authored-By lines, emoji, or marketing language.

The type isn't decoration — `/version` reads these to work out the next [Semantic Version](https://semver.org/): `feat` implies a minor bump, `fix` a patch, a breaking marker a major (minor while pre-1.0), and `docs` / `chore` / `refactor` / `test` / `ci` imply no release at all. Calling a feature `chore` hides it from the release; calling a refactor `feat` inflates the version. Pick the type that's true.

### 4. Output

- Print the commit message inside a single fenced code block so it's easy to copy.
- Do not run `git commit`, do not stage files, do not modify the repo.
- After the code block, optionally add one short line if something is worth flagging (e.g. "there are also unstaged changes in X you may want to include").