write-commit

What This Skill Does

Analyzes all local changes, groups them into logical commits, presents a plan for approval, then executes each commit in sequence.

Steps

1. Gather Context

Run these commands to understand the current state:

git diff HEAD
git status
git log --oneline -10

Also use any context from the current conversation — what feature, bug, or task was being worked on.

If an argument hint is provided, use it as a hint to guide how changes are grouped or labeled.

2. Build the Commit Plan

Analyze the diff and group changes into logical, atomic commits. Each commit should:

• Represent one coherent unit of work (one feature, one fix, one refactor, etc.)
• Follow Conventional Commits format: type(scope): description
  • Types: feat, fix, refactor, chore, test, docs, style, perf, ci
  • Scope is optional but encouraged when it clarifies context (e.g., fix(auth): ...)
  • Description: lowercase, imperative mood, no period at end
• List the exact files to stage for that commit

Example grouping logic:

• Changes to unrelated features → separate commits
• Test file + the code it tests → same commit
• Config/dependency updates → their own chore: commit
• Untracked new files are included if they're relevant to a commit's scope

3. Present the Plan

Show the plan clearly before doing anything. Format:

## Commit Plan

**Commit 1:** feat(auth): add JWT token validation
Files:
  - src/auth/validator.ts
  - src/auth/middleware.ts

**Commit 2:** test(auth): add tests for JWT validator
Files:
  - src/auth/validator.test.ts

**Commit 3:** chore: update dependencies
Files:
  - package.json
  - package-lock.json

Then ask: "Does this plan look good? You can approve it, ask me to adjust grouping, or modify specific commit messages."

4. Wait for Approval

Do NOT proceed until the user explicitly approves. If the user:

• Approves → go to Step 5
• Requests changes → revise the plan and show it again, repeat until approved
• Rejects → stop and ask what they'd prefer instead

5. Execute the Commits

For each commit in the plan, in order:

1. Stage the files: git add <file1> <file2> ...
   • New/untracked files may be staged if relevant
2. Commit: git commit -m "<message>"
3. Confirm the commit succeeded before moving to the next one

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

Notes

• Never mention claude as author in the commit
• Never push to remote — only commit locally
• Never skip confirmation — always show the plan and wait for approval
• Never use dangerous flags — no --force, --no-verify, --amend (unless explicitly asked)
• If there are no changes (git diff HEAD is empty), tell the user there's nothing to commit
• If changes are too large or complex to confidently group, say so and ask for guidance
• Keep commit messages concise — the subject line should be under 72 characters
• If a body is warranted (complex change), add it after a blank line in the commit message