Our review

Stages and commits changes using a standardized format with type prefixes.

When to use it

Use when you need to commit changes with a clear, standardized message that follows conventional commits.

When not to use it

Avoid when you need to write a detailed commit body or when changes are not ready for a single cohesive commit.

name: commit description: Stage and commit changes with standardized format user-invocable: true disable-model-invocation: true

Standardized Commit

!git status --short

!git diff --stat

!git diff --cached --stat

Based on the git status and diff above:

Stage changes if not already staged:
- Stage relevant files (use judgment on what belongs together)
- Do not stage unrelated changes
- Do not stage files that likely contain secrets (.env, credentials, tokens)
Write commit message in this format:
```
<type>: <description>
```
Types:
- fix: Bug fix
- feat: New feature
- refactor: Code restructuring (no behavior change)
- docs: Documentation only
- test: Adding/updating tests
- chore: Build, config, tooling changes
Rules:
- Description is lowercase, no period at the end
- Keep under 72 characters total
- Be specific: not "fix bug" but "fix null pointer in request handler"
- Use imperative mood: "add feature" not "added feature"
Commit without asking for confirmation. Use a HEREDOC for the message:
```
git commit -m "$(cat <<'EOF'
<type>: <description>
EOF
)"
```

Good:

Bad: