name

description

commit

Analyzes all git changes (staged and unstaged) in the current repository, groups them into logically cohesive commits, proposes a commit plan using conventional commits format (title-only, no scope unless the user requests it), and executes the commits after user approval. Use this skill whenever the user runs /commit, asks to "commit my changes", wants to "stage and commit", or says things like "make commits for my changes" — even if they don't explicitly ask for grouping or conventional commits.

Commit Skill

Your job is to turn the current working tree into a clean series of well-named commits — each one logically coherent, each message following the conventional commits format.

Step 1: Understand the changes

Run these in parallel:

• git status -u — see all files including untracked
• git diff HEAD — see the full diff of staged + unstaged changes
• git diff --name-only --diff-filter=A HEAD — find newly added (untracked) files
• git log --oneline -5 — get a feel for the project's commit history

Untracked files (new files not yet staged) should be included in the analysis. Use git diff --no-index /dev/null <file> or simply read the file content to understand what untracked files contain, so you can group them correctly.

Read the output carefully. You're looking for natural seams in the work: a bug fix mixed in with a new feature, config changes alongside application code, test additions bundled with the thing being tested.

Step 2: Group the changes

Think about what belongs together. A good group is one where, if you described it in a single sentence, every file in it fits that sentence. Common groupings:

• A new feature and its tests are separate commits — feat: first, then test: for the test files
• A bug fix stands alone — its tests get their own test: commit too
• Dependency or config changes are usually their own commit
• Refactors that don't change behavior stay separate from feature work
• Database migrations go with the entity/model changes they support

It's fine to have just one commit if the work is truly unified. Don't force artificial splits.

Step 3: Propose the plan

Present the proposed commits clearly, like this:

Here's my proposed commit plan:

1. fix: correct null check in payment processor
   Files: src/PaymentProcessor.cs, tests/PaymentProcessorTests.cs

2. feat: add webhook signature validation
   Files: src/WebhookValidator.cs, src/WebhookFilter.cs, tests/WebhookValidatorTests.cs

3. chore: update CRB integration NuGet package to 9.0.3
   Files: MyProject.csproj

Proceed with these commits? (You can tell me to adjust any of them)

Wait for the user to confirm or request changes before doing anything.

Step 4: Execute

Once approved, for each commit:

1. Stage only the files for that commit using git add <specific files> (never git add -A or git add .)
2. Create the commit

Pass the message via heredoc to avoid quoting issues:

git commit -m "$(cat <<'EOF'
feat: add webhook signature validation
EOF
)"

After all commits are done, run git log --oneline -5 and show the result so the user can see what was created.

Commit message format

Follow Conventional Commits:

• Title only — no body, no footer
• No scope unless the user asks for one
• Lowercase after the type prefix
• Imperative mood — "add", "fix", "remove", not "added", "fixed", "removed"
• Under 72 characters

Types:

Type	When to use
feat	New capability or behavior
fix	Bug fix
refactor	Code restructuring without behavior change
test	Adding or modifying tests
chore	Maintenance, dependencies, tooling
docs	Documentation only
style	Formatting, whitespace (no logic changes)
perf	Performance improvement
ci	CI/CD pipeline changes
build	Build system or compilation changes

Examples:

• feat: add OAuth2 token caching with SemaphoreSlim
• fix: prevent replay attacks in webhook timestamp validation
• refactor: extract payment status logic into dedicated service
• test: add integration tests for CRB webhook processor
• chore: upgrade Zebedee.MQ to 9.0.3

Important constraints

• Never skip pre-commit hooks (--no-verify)
• Never commit files that look like secrets (.env, credential files) — warn the user instead
• Never use git add -A or git add . — always stage specific files
• Never amend existing commits — always create new ones
• Don't push unless the user explicitly asks