| name | commit |
| description | Atomic, semantic-boundary git commit workflow |
/commit — Atomic Commit Workflow
When to use
When the user runs /commit or asks to commit changes.
Steps
- Run
git status and git diff --staged to understand what's changed
- If nothing is staged, identify logical change groups and stage them separately
- Write a commit message following Conventional Commits:
- feat: new feature
- fix: bug fix
- refactor: code restructuring
- docs: documentation
- test: tests
- chore: tooling/build
- Use the imperative mood in the subject line
- Keep subject under 72 characters
- Add body with "why" not "what" if the change isn't self-evident
- Create the commit using a heredoc for the message
- Run
git status to verify
Rules
- NEVER use --no-verify or --amend unless explicitly asked
- NEVER stage .env, credentials, or secret files
- Prefer multiple small commits over one large commit
- Each commit should compile and pass tests independently