Fulcrum 15 of 18
Committing the work
When changes are turned into a commit.
What goes wrong here
A commit records what changed, not why it was worth doing. Unrelated changes get bundled together, and the person approves a batch they couldn't see clearly.
How it compounds if nothing catches it
The next session sees code without its reason. Deliberate work looks accidental, so it gets 'cleaned up', and settled questions get asked again. The history of changes is complete, but the history of decisions is lost.
What the harness does here
After every git commit, a hook checks that a note was written to the Commit Intent Ledger in the last few minutes, and speaks up if not. A ledger note is a plain-language record of what a person can now do and why it mattered. The same hook closes any proposals the commit resolved. batch groups uncommitted changes by concern and walks through what each one means for people before committing. commit2 traces uncommitted code back to the intent it came from. commit makes the commit itself.
The pieces that act here
- post-bash-router.sh
A hook: a script Claude Code runs on its own at a set moment.
- /commit
Handle git commits with structured messages and staged file control. Use when asked to commit, stage, or push changes.
- /commit2
Pre-commit intent tracing gate. Spawns an agent team to trace uncommitted code back to its originating intent (compactions, sessions, intent DB), evaluate whether the code delivers on that intent, and present the person with a decision menu before committing. Use when running /commit across repos or when uncommitted work needs intent verification before staging.
- /batch
Review uncommitted files, group them by concern, and walk through each batch with UX impact analysis before committing. Chat is the default review surface; if the person has a notes vault (Obsidian or similar) set up, offer a one-note-per-concern dashboard with approve/reject/request-evidence controls instead.
- /batch-whats-next
Present finished, already-verified work — a batch ready to commit, a delegated fix that came back, a re-proposal after a gap was closed — as a set of per-item cards the person you're working with can say yes/no/hold to, each one framed as the intent that must be true if the work is aligned, never as a description of what the code now does.