git-commit

name	git-commit
description	Commit staged files with a precise, well-crafted commit message. Use when the user asks to commit, make a commit, or says "commit". Handles pre-commit hook failures, lint fixes, and safe re-staging.
metadata	{"version":"0.0.2","author":"walterra","repository":"https://github.com/walterra/agent-tools"}

Git Commit

Commit currently staged files with an accurate, concise commit message.

Workflow

Step 1: Identify staged files

Record the list of staged files. This list is the source of truth for the entire workflow.

git diff --cached --name-only

If nothing is staged, inform the user and stop.

Step 2: Analyze changes and commit

Analyze the actual diff to understand what changed:

git diff --cached

Then commit with a one-liner message:

git commit -m "<message>"

Commit message rules

• Max 60 characters.
• Describe what was done accurately. Analyze the diff — don't default to generic verbs like "add" when files were modified, updated, or refactored.
• No credit information. No "generated with", "co-authored-by", or similar.
• Conventional commits / semantic prefixes — only use them if the project already uses them (check recent git log --oneline -10).

Step 3: Check for pre-commit hook failures

If the commit succeeded, you're done. If pre-commit hooks failed (linting, type-checking, formatting), continue below.

Step 3.1: Auto-fix with project tooling

Run the project's own maintenance commands to fix issues automatically:

# Examples — use whatever the project has
pnpm lint --fix
pnpm format
pnpm tsc:check
npm run lint

Step 3.2: Fix remaining issues manually

If auto-fix didn't resolve everything, fix the remaining issues by hand.

Step 3.3: Re-stage the original files (with a narrow exception)

CRITICAL: Re-stage only files from the list captured in Step 1 — except for new files that are required to satisfy linting rules.

git add <file-from-step-1>

If linting/formatting requires refactoring into helper files (e.g., max file length, complexity rules), you may stage newly created files only when:

• The new files are direct refactors of the originally staged changes, and
• They are necessary to make linting pass without deleting content or taking shortcuts.

Step 3.4: Never stage unrelated extra files

• NEVER use git add . or any bulk staging command.
• If a formatter or linter modified a file that was not in the Step 1 list and is not a required new helper file, leave it unstaged.

Example: If only A.ts was originally staged, but linting requires extracting utilities into helpers.ts, you may stage helpers.ts along with A.ts. If a formatter also touched B.ts, leave B.ts unstaged.

Step 3.5: Retry the commit

git commit -m "<message>"

Use the same message from Step 2 (or refine it if fixes changed the scope).