| name | commit |
| description | Create a git commit following project conventions. Use when asked to commit changes. |
| argument-hint | [optional commit message override] |
| allowed-tools | Bash, Read, Grep |
Commit Changes
Create git commits following the Conventional Commits specification.
Commit Message Format
<type>[optional scope]: <description>
[optional body]
Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore
Scope: api, portal, or omit for cross-cutting changes that span both apps as part of the same feature
Description (first line):
- Imperative present tense ("add" not "added")
- Lowercase — no capitalization of first word
- No period at end
- Be specific and descriptive — capture enough context so the commit is self-explanatory
Body (optional, after blank line):
- Use when the description alone isn't enough to explain the change
- Explain what and why, not how
Forbidden:
- No
Co-Authored-By, Signed-off-by, or AI attribution lines — ever
Examples:
feat(api): add WhatsApp provider support
fix(portal): prevent duplicate form submission on login
refactor(api): extract org resolution into shared utility
feat: add SUPER_ADMIN org context switching across all controllers and portal
feat(api): add provider chain CRUD endpoints
Adds create, update, soft-delete, and restore endpoints
for provider chain members with org-scoped access control.
Steps
- Run
git status and git diff --stat to review all changes
- If
$ARGUMENTS is provided, use it as the commit message (still validate format)
- Otherwise, analyze the diff and group changes by nature:
- Each commit must be a single logical unit — one concern per commit
- Split when changes span different concerns:
- Bug fixes vs new features
- Refactors vs functional changes
- Database migrations vs application code
- Unrelated API changes vs unrelated portal changes
- Keep together when changes serve the same purpose (e.g. a feature that touches both API and portal)
- For each commit group:
a. Draft a message following the format above
b. Stage only the relevant files (prefer specific files over
git add -A)
c. Commit using a HEREDOC:
git commit -m "$(cat <<'EOF'
<type>(<scope>): <description>
EOF
)"
- Run
git status to verify success
Important
- Never include attribution lines (Co-Authored-By, Signed-off-by, noreply@anthropic)
- Never skip pre-commit hooks (
--no-verify)
- If hooks fail, fix the issue and create a NEW commit (don't amend)
- Don't push unless explicitly asked