Our review

Stages relevant changes and creates a well-formatted commit message following conventional commit standards.

When to use it

Use when you want to quickly commit changes with a properly formatted message without manual typing.

When not to use it

Do not use when you need to craft a detailed multi-line commit message or when you want to review staged changes manually.

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: