commit

Stage and commit the current working tree.

Guardrails

A few things that matter, and why:

• Keep commits focused — one concern per commit. A bug fix and a refactor, even if both are tiny, go in separate commits. This is what makes git log and git blame useful later, and it's what lets reviewers (and git revert) isolate one change without dragging in others.
• Don't push, force-push, amend, reset, or touch the remote. Those belong to /pr or the user. This skill's job ends at the local commit — staying in that lane keeps the two operations reviewable independently.
• Don't bypass pre-commit hooks with --no-verify. Hooks exist to catch real problems (lint, types, secrets). If one fails, the commit didn't happen — fix the underlying issue and commit again. Do not --amend after a hook failure: since the commit didn't land, --amend would rewrite the previous commit, quietly overwriting earlier work.
• Stage explicit paths, not git add . / -A. Wildcards sweep in whatever's lying around — .env, credentials, build artifacts, half-finished scratch files. Naming paths explicitly keeps that stuff out.
• Follow the global CLAUDE.md rule: "Split commits by logical concern; each commit leaves the codebase working."

Steps

1. Survey the working tree — run in parallel:

   git status
   git diff --stat
   git log --oneline -10
   

   • status + diff --stat show the full picture of what changed.
   • log --oneline -10 shows the repo's existing commit style so your messages match it.
   • If the tree is clean (nothing staged, nothing unstaged, no untracked relevant files), stop and tell the user there's nothing to commit.

2. Read the actual diffs — for any files where the nature of the change isn't obvious from the path, run git diff <file> (or git diff --cached <file> for already-staged changes) so you understand what each hunk does. Don't guess — a file named auth.go could contain a typo fix or a complete rewrite.