commit

name	commit
description	Create a git commit with proper conventional commit message
argument-hint	[optional message hint]
disable-model-invocation	true
allowed-tools	Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git log:*), Bash(git branch:*)
model	haiku

Context

• Current branch: !git branch --show-current
• Status (compact): !git status --short
• Staged changes: !git diff --cached
• Unstaged changes: !git diff
• Recent commits (for convention reference): !git log --oneline -10

User hint

$ARGUMENTS

Conventional Commits format

This project uses Conventional Commits. Every commit message MUST follow this format:

<type>(<scope>): <short description>

Types

Type	When to use
feat	New feature or capability
fix	Bug fix
refactor	Code restructuring without behavior change
chore	Maintenance, dependency updates, config tweaks
docs	Documentation-only changes

Scope rules

• Use the module or area name in kebab-case (e.g., waybar, claude-code, ghostty, netbird)
• Use deps for dependency/flake-input updates (e.g., chore(deps): update spirenixvim to 7aafdf7)
• Omit scope only when changes span many unrelated areas

Description rules

• Lowercase, imperative mood, no trailing period
• Focus on the why or what changed, not the obvious "what files were touched"
• Keep under 72 characters

Body (optional)

• Skip for trivial/single-concern changes
• For larger changes, add a blank line after the subject then prose paragraphs or dash-bullet lists

Real examples from this repo

feat(netbird): add netbird service module
fix(zen): suppress XDG migration warning
chore(deps): update spirenixvim to 7aafdf7
refactor(ghostty): remove tmux auto-start, add tmux to claude-code deps

Steps to follow

1. Check for changes — Look at the status and diffs above. If there are NO staged or unstaged changes, tell the user there is nothing to commit and stop.

2. Check for sensitive files — Scan the file list for .env, *.key, *.pem, credentials*, sops*, *.age, and secrets files. If any are present, warn the user and do NOT stage them. Ask for confirmation before proceeding.

3. Stage files — Only stage files that were part of the current session's work. If other unrelated changes exist in the working tree, leave them unstaged unless the user explicitly requests otherwise. Stage files explicitly by name using git add <file> ... — never use git add -A or git add .. Never stage files that appear to contain secrets.

4. Write the commit message — Draft a message following the Conventional Commits format above. If the user provided a hint in $ARGUMENTS, incorporate it. The message must:

   • Use the correct type and scope
   • Be concise and accurate
   • NEVER mention "Claude", "AI", "generated by", "co-authored", or any attribution

5. Create the commit — Use a HEREDOC so multi-line messages are formatted correctly:

   git commit -m "$(cat <<'EOF'
   <type>(<scope>): <description>
   
   Optional body here.
   EOF
   )"
   

6. Confirm — Run git status after the commit to verify it succeeded. Report the commit hash and message to the user.

Important rules

• NEVER amend a previous commit. Always create a NEW commit.
• NEVER use --no-verify or skip pre-commit hooks.
• NEVER push to remote — only commit locally.
• If a pre-commit hook fails, fix the issue, re-stage, and create a NEW commit (do not amend).
• If there are no changes to commit, say so and stop — do NOT create an empty commit.
• Only commit changes from the current session. If unrelated modifications exist in the working tree, leave them alone unless the user explicitly asks to include them.