commit

Prompt file imported from ioandev/glu (.claude/commands/commit.md). Fill in {{arguments}} before use. Copyright stays with the author.

Extra instructions from the user: {{arguments}}

Analyse everything that is not yet committed in this repo and write a ready-to-use commit message to COMMIT.md at the repo root.

Hard rules

1. NEVER commit. Do not run git commit, git add, git stage, git rm, git restore, git checkout, git stash, git reset, git clean, git push, or anything else that changes the index, the worktree, or a ref. This command is read-only against git. The only file you write is COMMIT.md.
2. Do not stage anything to "make the analysis easier." Staged and unstaged changes are analysed exactly as they are.
3. COMMIT.md is gitignored and is overwritten in full on every run. If it already exists, replace it — do not append, do not merge with the old text.
4. Write only what the diff actually shows. No speculation about intent, no "should also", no TODOs, no future work.

Step 1 — collect the full picture

Run these (read-only) and read the actual output, all of it:

git status --porcelain=v1 -uall
git diff --stat && git diff --cached --stat
git diff && git diff --cached

Then, for every untracked file listed by git status (??), read its contents with the Read tool — untracked files are part of the prospective commit and git diff does not show them. Ignore COMMIT.md itself.

If a diff is very large, do not skim: read it in chunks (per path, via git diff -- <path>) until you have actually seen every hunk. A message that misses a third of the change is worse than no message. If the total change is genuinely enormous, still read every path's stat line and read the diffs of every file whose change is not purely mechanical (formatting, lockfile, generated output) — and say in your reply which files you treated as mechanical.

Also skim git log --format='%s' -20 so the subject line matches the repo's existing voice.

Step 2 — understand it as GLU work

This repo is ADR-driven (see CLAUDE.md). Before writing anything:

• Work out which ADR(s) the change belongs to. If a diff touches docs/adr/NN-*.md, read the changed part — an ADR edit tells you whether this is a new decision, an amendment, a deviation being recorded, or a status flip to Implemented.
• Note ADR numbers in the message where they explain why a change exists. (ADR 24) beats a sentence of re-explanation.
• Generated files (LICENSES manifests, web/public icons, lockfiles) get one line, not a breakdown.
• Group by what changed for the user or the system, not by directory listing. "Backend and web both learn X" is one bullet, not two.

Step 3 — write COMMIT.md

The file contains exactly the commit message and nothing else — no markdown headings, no code fences, no preamble, no trailers, no "Generated by" note. It must be usable verbatim as git commit -F COMMIT.md.

Structure:

<type>: <subject, imperative mood, lower-case after the colon, ≤72 chars>

<one short paragraph of context: what this change is and why it exists — only
if the subject line doesn't already say it. Skip entirely for small commits.>

feature:
- <what was added, and where — one line each>
- <...>

fix:
- <what was broken and is now not, one line each>
- <...>

Rules for the structure:

• <type> is feature or fix — those exact words, not feat, not chore, not refactor, not a scope in parentheses.
• Small/single-purpose commit: subject line only, or subject + one short paragraph. Do not add feature:/fix: sections that would just restate the subject.
• Big commit with both kinds of change: pick the type that dominates for the subject line, then use both feature: and fix: body sections. Omit a section that would be empty.
• Big commit of one kind: subject line of that type plus the matching body section listing the parts.
• Bullets are one line each, present tense, concrete. Name the surface (backend/todoistRoutes.ts, "the settings Screen section", "ADR 27") rather than saying "various files".
• Purely mechanical churn (formatting, regenerated LICENSES, lockfile bumps) collapses to a single trailing bullet in its section.
• No emoji, no attribution trailers, no Co-Authored-By, no session links — the person running the commit adds whatever trailers they want.

Step 4 — report back

In your reply to the user (not in the file):

• State the path you wrote and show the message you produced.
• List the counts you worked from: N staged files, N unstaged, N untracked.
• Flag anything that looks like it does not belong in this commit — a stray debug line, a committed secret, a .env, a large generated blob, an unrelated experiment. Say it plainly; do not remove it yourself.
• If an ADR-relevant change appears to have no matching ADR update, say so — CLAUDE.md requires deviations to be recorded in the ADR in the same session.
• End by reminding the user that nothing was committed and that COMMIT.md is gitignored.

If there is nothing uncommitted at all, do not create the file — just say the worktree is clean.