commit（提交）

Git Commit Workflow

Direct execution of git commit workflow - no agent delegation, fast and simple.

Trigger Phrases

This skill activates on:

• "commit changes", "commit this", "commit my work"
• "save to git", "save my changes", "save this to git"
• "push this", "push my changes", "push my work"
• "create a commit", "make a commit"
• "git commit", "check in my changes"

Proactive Triggering

After completing implementation work, proactively offer to commit:

• "I've finished implementing the feature. Would you like me to commit these changes?"
• Use AskUserQuestion with options: "Yes, commit now" / "No, I'll review first"

Workflow

Step 1: Assess Changes

git status
git diff

If no changes: Report "No changes to commit" and end.

Step 2: Stage Files

Stage logically related changes:

git add <files>

Skip sensitive files:.env, credentials, tokens - warn user if detected.

Step 3: Create Conventional Commit

Analyze changes and determine:

• Type: feat, fix, docs, style, refactor, perf, test, chore
• Scope: Component/area affected
• Subject: Imperative, lowercase, max 50 chars, no period

Commit format:

<type>(<scope>): <subject>

[Narrative body explaining WHAT and WHY - 2-4 sentences, NO bullet points]

Good example:

feat(auth): add session timeout handling

Implements automatic session refresh when user activity is detected
within the timeout window. Sessions now persist across page reloads
using localStorage with encrypted tokens.

Bad example (avoid):

feat(auth): add features

- Added timeout
- Added refresh
- Added localStorage

Step 4: Execute Commit

git commit -m "$(cat <<'EOF'
<commit message here>
EOF
)"

Step 5: Handle Pre-commit Hooks

If hooks modify files:

1. Stage the modified files
2. Amend the commit: git commit --amend --no-edit

Step 6: Ask About Push

Use AskUserQuestion:

• "Commit successful! Push to remote?"
• Options: "Yes, push now" / "No, keep local"

Step 7: Push (if confirmed)

git push
# or if no upstream:
git push -u origin <branch>

Gotchas

• Pre-commit hooks that modify files (formatters, linters) require re-staging — after hook failure, stage modified files and create a NEW commit (don't amend, as that modifies the previous commit)
• git add. can accidentally stage unrelated files — prefer staging specific files by name
• Claude tends to write commit bodies as bullet lists — use narrative prose (2-4 sentences) instead
• When no upstream branch exists, git push fails silently — must use git push -u origin <branch>
• Never amend commits already pushed to shared branches — this rewrites history others may have pulled

Safety Rules

• NEVER commit.env files or credentials
• NEVER force push without explicit user request
• NEVER amend commits on shared branches without warning
• Always show what will be committed before committing