sensible-commit-flow
Sensible Commit Flow
Every commit should have a clear purpose, and the history should show how the changes fit together.
This skill helps agents group changes by intent, order commits by dependency, and write messages that explain their purpose. It establishes the user’s approval before creating commits or revising history, then verifies the recorded result while preserving unrelated work.
Select Workflow
Load only the selected route and its applicable references.
- Prospective planning: Before changes exist, follow Plan Before Implementation and return to the calling workflow without entering confirmation or execution.
- Read-only preparation: For requests limited to grouping existing changes or drafting or revising message text, use Inspect Changes and Group Hunks when the result depends on actual changes, and Compose Messages when wording is requested. Return the requested result without entering confirmation or execution. Changing a recorded commit’s message is a history update, not prose-only work.
- Concrete proposals and execution: Before preparing a concrete commit proposal or invoking commit tooling, load Commit Execution, including for already authorized operations that don’t need a proposal presentation. For new commits assembled from working tree changes, prepare through Inspect Changes, Group Hunks, and Compose Messages. For cherry-picks and merges that create commits, including continuation after a pause, use Preserve Operation Messages. Select Update Commit History only when the user or an applicable calling workflow explicitly requests a history update or rebase, including a request to fold changes into their original commits. For scripts or tests that create commits, use the execution reference’s invocation checks to establish their targets and select their preparation route before invocation.
For newly authored messages, proposal explanations, and result prose, apply Compose Prose within the selected route.
Establish Authorization
Keep preparation read-only until you establish user authorization through Confirm Commits. None of these alone authorizes staging, direct or indirect commit creation, or history rewriting: accepted findings, an approved implementation plan, completed edits, passing checks, or staged changes. Only the user can approve execution. An agent can’t approve its own proposal or treat a tool grant as authority for another effect.