Generates conventional commit messages following Conventional Commits spec strictly. Use this skill whenever the user wants to commit changes, stage and commit, push to a branch, or asks for a commit message. Even if the user just says "commit this", "I want to push", "make a commit", or "subir cambios" — always use this skill. Never commit without explicit user confirmation.
Generate strict conventional commit messages, show them for confirmation, then commit.
git status
git diff --staged
If nothing is staged, tell the user and ask if they want to stage specific files or everything (git add .).
Before writing a single commit message, ask: do these staged changes belong to the same concern?
Split into separate commits when staged files touch unrelated modules or concerns. For example:
If a split makes sense, tell the user:
I see changes in two unrelated areas. It'd be better to split these into two commits:
1. build(ios): upgrade deployment target to iOS 16
2. chore(deps): bump react-navigation and lodash
Want me to stage and commit them one by one?
Wait for their confirmation before proceeding.
Always follow Conventional Commits — no exceptions.
type(scope): short description
Optional body — only when the why isn't obvious from the subject line.
BREAKING CHANGE: description ← only if applicable
| Type | When to use |
|---|---|
feat | New feature or behavior |
fix | Bug fix |
refactor | Code change with no feature or bug impact |
chore | Maintenance, config, dependency updates |
ci | CI/CD changes |
docs | Documentation only |
test | Adding or fixing tests |
perf | Performance improvement |
build | Build system or tooling |
style | Formatting, whitespace — no logic change |
auth, checkout, profile, deps)The body is optional. Only add it when the subject line alone doesn't explain why the change was needed. When in doubt, skip it.
Good example (body needed):
fix(auth): redirect to login when session expires
Token expiration was not being caught, leaving users on a blank screen.
Good example (no body needed):
chore(deps): upgrade axios to 1.7.2
BREAKING CHANGE: <description> in footer! to the type: feat!(auth): ...Present it clearly:
Here's the commit message:
---
fix(auth): redirect to login when session expires
---
Good to go? I'll commit once you confirm.
Never run git commit before the user confirms. Always wait for an explicit "ok", "yes", "sí", "lgtm", or similar.
Once confirmed:
git commit -m "$(cat <<'EOF'
type(scope): short description
EOF
)"
Use a heredoc to preserve formatting. Show the result with git log --oneline -1.