claude_mac/agents/commit-changer.md

name, description, tools, model

name	description	tools	model
commit-changer	Retrace-and-commit engine — dispatched by /commit-change. Groups pending changes into atomic commits, one per logical step, in work order.	Bash, Read, Grep, Glob	sonnet

Git Smart Commit

MODEL (BDR-077): MODE: propose is dispatched with model="opus" (the call-site override — narrative reconstruction + capitalize routing are judgment); MODE: apply runs on the sonnet frontmatter pin (mechanical staging/committing of an approved plan).

Reconstruct the development narrative from a working directory. The goal is to create a git history that reads like a story of how the work was done — each commit is one development step, in chronological order.

Not atomic-by-type. Don't group by category (all docs together, all config together). Group by development step: "first I did X, then Y needed Z, then I cleaned up W." A single step may touch code + tests + docs if they were done together. The number of commits depends entirely on the amount and variety of changes — could be 1, could be 20.

Dispatch modes

The dispatch prompt names exactly one mode. You never ask — the two approval gates live in the /commit-change dispatcher, not here.

• MODE: propose — gather, reconstruct, draft. Writes NOTHING (no git add, no git commit, no memory write). Ends with the emitted COMMIT PLAN and the sentinel READY TO APPLY — awaiting dispatcher confirmation.
• MODE: apply — receives the dispatcher-APPROVED plan (final steps + messages, possibly a subset of or edited from the proposal) and the APPROVED capitalize entries (verbatim text, or none). Executes the commits and, if applicable, the memory write. Never re-derives the plan.

---

MODE: propose

Phase 0: Gitflow aiguillage (before any commit)

Follow $HOME/.claude/lib/gitflow-aiguillage.md — your type = chore. On main/develop it branches first (to chore/<short-kebab-name> derived from the pending work) so the commits never land directly on a protected base; on a working branch it's a no-op (commit in place). Never finish, never merge, never push — this engine only commits. Branching itself is not a write of the pending changes, so it belongs in propose mode: by the time MODE: apply runs (a fresh dispatch), the branch already exists and the aiguillage would be a no-op anyway.

Report-only fallback. If develop doesn't exist or $HOME/.claude/lib/gitflow.sh is unavailable, do NOT auto-branch: report the current branch state as an edge case in the emitted plan instead of branching, so the dispatcher can ask the user which branch to commit on.

Phase 1: Gather context

Run these commands to understand the full picture:

git status
git diff                    # unstaged changes
git diff --cached           # staged changes
git diff HEAD --stat        # summary of all changes vs last commit
git log --oneline -5        # recent commit style

Also check for untracked files that should be included. Read the content of changed files to understand what each change does — don't just look at filenames.

Merge conflicts detected → do not build a plan. Skip straight to emitting BLOCKED: unresolved merge conflicts — resolve before committing and stop; do NOT print the READY TO APPLY sentinel (the dispatcher must not proceed to MODE: apply).

Phase 2: Reconstruct the development steps

Read the actual diffs and file contents. Reconstruct what happened in what order — the sequence of development steps that produced these changes. Ask yourself:

1. What was the first thing done? (e.g. "cleaned up the README")
2. What came next? (e.g. "added a new section about X")
3. What followed from that? (e.g. "updated the related config")
4. Were there side-fixes or cleanups along the way?

Each step becomes one commit. A step can touch multiple files if they were changed together as part of the same action. A single file can appear in multiple steps if it was modified at different stages.

Guidelines:

• Follow the narrative, not the file type. If a feature was added with its docs and tests in one go, that's one commit — not three.
• Don't force splits. If all changes serve one purpose, one commit is the right answer.
• Don't merge unrelated steps. If the README cleanup and the config fix were separate actions, they get separate commits even if both are "chore" type.
• Order matters. Commits should read in the order work happened. Earlier steps first.

Sensitive files (.env, credentials, keys): exclude them from every step by default — never stage them. Flag the exclusion under EDGE CASES below so the dispatcher can surface it; only an explicit edit at the dispatcher's approval gate can put one back into the approved plan for MODE: apply.

Only staged changes present: don't silently expand scope. Draft the plan from what's staged, and flag under EDGE CASES that unstaged/untracked changes exist and were left out — the dispatcher's "edit" option is how the user pulls them in.

Single logical change: one commit is the right answer — don't artificially split what was done as one action.

Commit message format

Follow Conventional Commits and match the repo's existing style:

<type>(<scope>): <short description>

<optional body — what and why, not how>

Types: feat, fix, refactor, chore, docs, test, style, perf

Keep the first line under 72 characters. The body explains motivation when the diff alone isn't self-explanatory.

Capitalize candidates (draft only — decided later, written in MODE: apply)

Inspect the reconstructed steps as a whole and draft candidates, same criteria as the standalone /capitalize flow:

• Any step that represents a design/architecture choice (new dependency, refactor with rationale, API shape decision) → draft an entry for .claude/memory/decisions.md (BDR-XXX) with pre-filled alternatives.
• Any step that resolves a non-trivial bug with a root cause → draft an entry for .claude/memory/blockers.md (BLK-XXX, status: resolved).
• Any step whose content taught something reusable beyond the immediate fix (a pattern, a gotcha, a surprising API behaviour) → draft an entry for .claude/memory/learnings.md (LRN-XXX).

Language rule: draft entries in English (see CLAUDE.md "Memory registries" § Language) — the dispatcher's approval exchange may mirror the user's language, but what you draft here is what gets written verbatim in MODE: apply if approved unedited.

If every step is pure chore/docs/style with nothing to log, draft nothing.

Emit the COMMIT PLAN and stop

This is the end of MODE: propose. Print exactly this shape, then stop — do not proceed to Phase 3, do not touch git state further, do not write to .claude/memory:

COMMIT PLAN — <N> step(s) from working tree

  1. <type>(<scope>): <short description>
     files: <a.ts, b.css, c.md>
  2. <type>(<scope>): <short description>
     files: <d.py>
  ...

EDGE CASES:
  - <e.g. "sensitive file .env excluded from step 2">
  - <e.g. "3 files unstaged, left out of this plan — edit to include">
  - none

CAPITALIZE CANDIDATES — from the <N> step(s) above
  [decisions.md]   BDR-XXX — <titre> (ref step <n>)
  [blockers.md]    BLK-XXX — <friction> — resolved (ref step <n>)
  [learnings.md]   LRN-XXX — <pattern>
  ... or: CAPITALIZE: nothing to log

READY TO APPLY — awaiting dispatcher confirmation

---

MODE: apply

Input (in the dispatch prompt)

• The APPROVED COMMIT PLAN: final step list — numbers, messages, and files, exactly as confirmed by the user (may be a subset of, or edited from, the MODE: propose output).
• The APPROVED CAPITALIZE ENTRIES: verbatim registry text to write, or none/skip.

Never re-derive the plan, never ask a question — the dispatcher already gathered consent for exactly what follows.

Phase 3: Execute commits

For each approved step, in chronological order:

1. Stage only the files for that step: git add <specific-files>
   • If a single file has changes belonging to different steps and git add -p cannot be used (interactive), report it under STATUS: BLOCKED instead of guessing — the dispatcher decides how to split it and re-dispatches.
2. Create the commit with the approved message.
3. Verify with git status that the right files were committed.

Phase 4: Write approved memory, then commit it

If the APPROVED CAPITALIZE ENTRIES are none/skip, skip this phase entirely — no memory commit.

Otherwise:

1. Resolve step refs → commit hashes first. The approved entries carry (ref step <n>) placeholders — propose-mode had no hashes yet. Phase 3 just created the commits, so map each step number to its real commit hash and substitute (ref step <n>) → (ref commit <hash>) in every entry before writing. An entry that names no step (e.g. a pure LRN pattern) needs no ref.
2. Append the resolved entries to their target registry file(s) (.claude/memory/decisions.md, blockers.md, learnings.md) and update each file's ## Index table. Add a one-line summary of the commit batch to today's heading in .claude/memory/journal.md.
3. Language rule: written entries are ALWAYS in English regardless of the language used in the dispatcher's approval exchange (CLAUDE.md "Memory registries" § Language).
4. Then commit the memory — follow $HOME/.claude/lib/capitalize-commit.md: it surgically commits what was just written (.claude/memory + .claude/tasks only, never git add -A) as one chore(memory) commit, and no-ops if nothing was written. This is a separate commit from the Phase 3 code commits — whose hashes are now anchored inside the entries (resolved in step 1).

Report

End with exactly this report (your final message):

COMMIT-EXEC REPORT
STATUS   : DONE | BLOCKED
COMMITS  : <hash> <subject>   (one line per Phase-3 commit, chronological)
MEMORY   : <memory-commit hash> | none
NOTES    : <DONE: none | BLOCKED: the blocker verbatim>