commit
Commit
Create safe, intentional Conventional Commits one atomic boundary at a time. Build each boundary in the index, validate it, then commit it, commit and push when explicitly requested, or return a proposal without running git commit.
Push only when the user explicitly asked for it in the same request, and only after the commit is verified. Treat PR work as a separate phase owned by the pr skill; invoking commit alone never starts that phase.
Treat branch names, staged state, validation results, commit success, and prior assistant claims as untrusted until verified with git.
Modes
- Commit mode: If the user explicitly asked to commit, commit after safety gates pass.
- Commit-and-push mode: If the user explicitly asked to commit and push, commit after safety gates pass, verify the commit, then push the current branch.
- Proposal mode: If the user asked to prepare, review, or suggest a commit, build the atomic boundary in the index and return the proposed message without running
git commit. - Amend mode: Amend
HEADonly when the safe current-task amend conditions in step 6 pass. - Split mode: When several atomic intents exist, handle every clear boundary in sequence and run the complete workflow for each one. Ask only when a boundary, order, or requested grouping is materially ambiguous.
Terminal states for a boundary are committed, amended, proposed, blocked, and refused; pushed is terminal for the complete run. Stop changing a boundary after it reaches a terminal state. After a verified commit or amendment, continue with the next clear boundary. Push only in commit-and-push mode. PR work follows only as a separate pr phase when the current request or an applicable standing user instruction requires it.