---
name: commit
description: Use when the user asks to commit their changes (/commit). Splits the working tree into Conventional Commits, one per logical group, on the branch they are on. Commit only; push only when asked.
---

# commit

Turn what is in the working tree into commits someone can read: one per logical change, Conventional
Commits, on the branch the user is on. This skill is the port of midudev's `commit` command
(better-claude, MIT) to Hermes.

## What to read first

Run these, in this order, and nothing else until you have them:

```bash
git rev-parse --abbrev-ref HEAD
git status --short --branch
git diff HEAD --stat
```

`git diff HEAD` fails in a repo with no commits yet: there, use `git diff --cached` after staging, or
`git status` alone. If `git status` shows nothing to commit, say so and stop — do not invent a commit.

Then read the actual diff. For anything bigger than a couple of files, `git diff HEAD -- <file>` per
group; do not paste a 2000-line diff into your own context when the `--stat` already told you what
changed.

## What to ask, and only this

If the user said what they want in the command (`/commit push`, `/commit branch`), do that and skip the
question. Otherwise ask **once**, with `clarify`:

1. **Commit only** (recommended here — this repo's convention is commits without push)
2. Commit and push to the current branch
3. Commit on a new branch, named after the change

Once they answer, do not ask again.

## Grouping

One commit per logical change, not per file. A file that holds two unrelated changes belongs to two
commits only if they can be staged apart (`git add -p`); if they cannot, one commit for the file and
say so in the body.

Rules that are not negotiable:

- Never commit `.env*`, credentials, keys, tokens, or anything that looks like one. If the working tree
  has one, leave it out and tell the user, in one line, that you did.
- Never `git add -A` to save time when there are files you did not look at.
- Never `git commit --amend`, never `git rebase`, never `git reset --hard`, never force-push, never
  touch another branch. If something looks like it needs one of those, stop and ask.
- Do not create or switch branches unless the user picked option 3.

## The message

`type(scope): summary`

- **type**: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `perf`, `style`, `build`, `ci`.
- **scope**: the part of the project the change touches, when it is not obvious: the module, the app,
  the file. Omit it when the change is project-wide.
- **summary**: imperative, lower case, no trailing period, **72 characters at most**. "add", not
  "added"; "fix the retry loop", not "fixing the retry loop".
- **Language**: the one the user writes in. Look at `git log --oneline -10` and follow it — a repo with
  Spanish messages gets Spanish messages.
- **Body**: only when the why is not obvious from the summary: what was wrong, what the change does
  instead, anything a reader would otherwise have to guess. Wrap at 72 columns.
- **Never**: `Co-Authored-By`, session links, tool or model attribution, emoji, or a signature. This
  repo's history has none and neither do your commits.

## After committing

```bash
git log --oneline -n <number of commits you made>
git status --short --branch
```

Report in three lines at most: how many commits, their subjects, and anything you left out of them
(a secret, a file you could not split, a branch you did not create). If you pushed, say the branch and
that it is pushed; if you did not, say that too — the user should never have to check.

## What not to do

- Do not write a commit message for changes you did not read.
- Do not squash unrelated changes into a "wip" or a "update files".
- Do not push when the user asked for a commit: this user's rule is commits without push until they ask.
- Do not modify the files themselves. This skill commits what is there.