---
name: committing-changes
description: This skill should be used when the user asks to commit, stage, split, or prepare changes for a commit. Examples: "commit this", "stage these", "split this into commits", "help me commit", "prepare a commit", "make a commit for the dcp fix".
---

# Committing Changes

Segment the working tree by concern, stage explicitly, draft messages, **present the plan, and STOP**. Commit only on the user's explicit command for this turn. Never push — the user pushes manually (Gitea + GitHub mirror).

**The default is to prepare and propose, not to commit.** A request to "commit X" is a request to get X *ready* and show the plan, unless the user has, in this turn, told you to actually run the commit. When in doubt, present and wait.

## Workflow

1. **Inspect.** `git status` then `git diff` (and `git diff --staged` if anything is already staged). Read what actually changed — do not commit from memory of what you wrote.
2. **Segment by concern.** Group the changes into buckets, one per coherent concern. State the grouping in plain language before staging anything (e.g. "two concerns: (a) the SSE fix in opencode-server.ts, (b) an unrelated typo in README").
3. **Safety scan.** Before staging, scan the diff for: secrets / keys / tokens, debug code, stray `console.log`/`print`/`dbg!`, commented-out experiments, and edits to files the user did not ask you to touch (their in-progress work). Flag anything found; do not silently stage it.
4. **Stage explicitly, per bucket.** Stage named files (`git add path/a path/b`) or hunks (`git add -p`). **Never `git add -A`, `git add .`, or `git add -u`** — those sweep up unrelated work. If `-p` can't cleanly split adjacent hunks, hand-edit the patch (`git add -e`) or revert the unrelated hunk in the working tree first.
5. **Draft messages.** One message per bucket, in the repo's scope-prefix style (see `references/message-style.md`). Explain *why* for anything non-obvious — the diff already shows *what*. Imperative mood. No emojis. Do not impose Conventional-Commits ceremony (type enums, `BREAKING CHANGE:` footers) unless the user asks.
6. **Present the plan + STOP.** Show: the buckets, the files in each, the drafted message for each, and the current staged state. Then wait. **Do not run `git commit`.**
7. **On the user's command**, execute the agreed `git add` / `git commit` exactly as presented, using the identity below. Then report the resulting hashes. Still do not push.

## Split heuristic

- **One commit** when the changes are a single coherent concern (a feature + its test; a fix + the comment explaining it).
- **Multiple commits** when concerns are independently revertable or reviewable — a bug fix and an unrelated refactor that happen to share the working tree should be two commits even if they touch the same file.
- A migration/schema change and the code that uses it are usually *one* concern (they're not independently revertable). A doc/changelog update alongside code is usually a *separate* concern.

## Identity (always)

Commit as:

```
user.name  = indifferentketchup
user.email = sam@indifferentketchup.com
```

Never use a personal Gmail or the host's default git identity. If unsure the repo config is right, pass it inline: `git -c user.name=indifferentketchup -c user.email=sam@indifferentketchup.com commit -m "..."`.

## DO-NOT

- **Never push.** No `git push` under any circumstances — that is the user's manual step (dual remote: Gitea + GitHub mirror).
- **Never auto-commit.** Preparing ≠ committing. Commit only when told to, this turn.
- **Never `git add -A` / `git add .` / `git add -u`.** Stage by name or by hunk.
- **Never commit the user's unrelated/in-progress files.** If a file changed that the task didn't touch, leave it; surface it.
- **No emojis** in messages.
- **No amending or rebasing** published or shared commits without an explicit instruction.

## Red flags — STOP

- About to run `git commit` without having been told to commit this turn → STOP, present the plan instead.
- About to `git add -A` "to save time" → STOP, stage by concern.
- About to `git push` "to finish the job" → STOP, that is never part of this skill.
- A secret or debug line is in the diff and you're staging anyway → STOP, surface it.

## Anti-patterns this skill avoids

- Committing the moment changes look done (the user reviews diffs and commits on command).
- Collapsing several concerns into one "WIP" commit because staging separately is tedious.
- Pushing after committing because the work "feels finished."
- Reformatting the message into strict Conventional Commits when the repo uses freeform scope-prefixes.
