| name | commit |
| description | Stage and commit changes with a clear, concise commit message. |
| argument-hint | ["optional message hint"] |
| allowed-tools | Bash(git *) |
Commit
Create a commit for the current changes.
Steps
- Run
git status (without -uall) to see untracked and modified files.
- Run
git diff and git diff --cached to understand staged and unstaged changes.
- Run
git log --oneline -5 to see recent commit style.
- Run
bin/test-confidence to verify your changes don't break anything. Opus analyzes your diff and runs the right tests. Wait for 99% confidence (green bar) before proceeding. If any test fails, fix it first.
- Run linters on changed files before staging:
- Ruby files:
bundle exec rubocop --force-exclusion -a <files>
- JS/TS files:
npm run lint-fast -- --max-warnings 0 --fix --no-warn-ignored <files>
- TypeScript type check:
npx tsc --noEmit (required, catches type errors that eslint skips)
- CSS/SCSS/JSON/MD files:
npx prettier --write <files>
- SVG files:
npx svgo --multipass <files>
- Fix any lint errors or type errors before proceeding. Do not commit code that fails linting or type checking.
- Stage the relevant files by name — avoid
git add -A or git add ..
- Write a commit message and commit.
If $ARGUMENTS is provided, use it as a hint for the message.
Commit message rules
- Use the imperative mood ("Add", "Fix", "Remove", not "Added", "Fixes", "Removed").
- Be concise: one short sentence, ideally under 50 characters.
- Do NOT use conventional commit prefixes (no
feat:, fix:, chore:, etc.).
- Do NOT add any
Co-Authored-By or similar trailers.
- Focus on what changed and why, not how.
- If a second line is needed for context, keep it brief.
Examples of good messages
Prevent discount code from being cleared on edit
Add integration test for offer code persistence
Remove unused legacy export helper
Fix thumbnail missing in upsell insert
$ARGUMENTS