commit

name	commit
description	Stage the current changes and create a git commit with a properly formatted English message. Use whenever the user asks to commit, save, or check in their work. Picks a Conventional-Commits-style prefix (fix:, feat:, refactor:, docs:, test:, chore:, style:, perf:) based on the actual diff, keeps the first line a concise summary, and adds a bullet list of details only when the change touches several things.
argument-hint	Optional: additional context about what changed, or which files to include
user-invocable	true
disable-model-invocation	false

Commit

Stage the outstanding changes and create a single git commit with an English message that follows this project's format.

User Input

$ARGUMENTS

Consider any additional context from the user input (e.g. "only commit the tool changes", "this is a bug fix") before proceeding.

Procedure

Step 1: Survey the Changes

Run in parallel:

• git status — see tracked and untracked files
• git diff and git diff --staged — see the actual content changes
• git log --oneline -10 — match the repository's existing commit message tone

Step 2: Stage the Changes

Stage the modified and new files that belong to this piece of work (git add <files>, or git add -A when everything in the working tree is part of the same change).

Before committing, look at the staged file list once more:

• If anything looks like a secret or credential (.env, *.pem, credentials.json, API keys, etc.), unstage it and warn the user instead of committing it silently.
• If some staged files clearly belong to unrelated, separate work (not what the user is asking to commit right now), leave them out and mention it to the user.

Step 3: Determine the Commit Type

Look at the diff and classify the change into a prefix:

Prefix	When to use
fix:	Bug fix
feat:	New feature or capability
refactor:	Restructuring without behavior change
docs:	Documentation only (README, YARD, locale text)
test:	Test-only changes
chore:	Tooling, dependencies, config, housekeeping
style:	Formatting/whitespace only, no logic change
perf:	Performance improvement

If a change spans multiple categories, pick the one that reflects the primary intent.

Step 4: Write the Commit Message

Format:

• Line 1: <prefix>: <concise summary of the overall change> — English, imperative mood, no trailing period.
• If the change is small (one focused fix, a single file, a short diff): stop at line 1. No body needed.
• If the change touches several things: leave a blank line after line 1, then a short bullet list (- ...), one line per notable change. Keep bullets brief — what changed, not how.

Example (small change):

fix: correct nil check in issue summary cache lookup

Example (larger change):

feat: add vector model profile support to settings

- add use_vector_model_profile and vector_model_profile_id columns
- update settings UI to select a dedicated vector model profile
- fall back to the default model profile when unset

Do not add a Co-Authored-By line or any other reference to Claude/AI assistance — this project's convention explicitly excludes that from commit messages.

Step 5: Commit

Use a heredoc so multi-line messages are formatted correctly:

git commit -m "$(cat <<'EOF'
<prefix>: <summary>

- <detail 1>
- <detail 2>
EOF
)"

Always create a new commit — never --amend an existing one unless the user explicitly asks for it.

Step 6: Confirm

Run git status after the commit and report the resulting commit (short hash + first line) to the user. Do not push.

Notes

• Never push — this skill only commits locally.
• Never use --no-verify to skip hooks.
• Write commit messages in plain English regardless of the conversation language.

Error Handling

• If there is nothing staged and nothing to stage (clean working tree), tell the user there is nothing to commit — do not create an empty commit.
• If a pre-commit hook fails, fix the underlying issue, re-stage, and create a new commit — do not amend the previous one (the failed commit never happened).
• If secrets or clearly unrelated files are detected among the changes, stop and confirm with the user before including them.