Claude-skill-registry auto-commit

Automatically commits and pushes significant changes to git after completing features, fixes, or milestones. This skill should be used proactively by Claude when meaningful work is completed, or invoked manually via /auto-commit. Triggers on feature completion, bug fixes, configuration changes, documentation updates, or when explicitly requested.

install

source · Clone the upstream repo

git clone https://github.com/majiayu000/claude-skill-registry

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/auto-commit" ~/.claude/skills/majiayu000-claude-skill-registry-auto-commit && rm -rf "$T"

manifest: skills/data/auto-commit/SKILL.md

Auto-Commit Skill

Automatically stage, commit, and push changes to git when significant work is completed.

When to Use

This skill activates when:

Feature completion - A new feature, component, or module is fully implemented
Bug fix - A bug has been identified and fixed
Configuration/setup changes - Project configuration, dependencies, or settings modified
Documentation updates - README, PRD, or other docs created/updated significantly
Refactoring complete - Code restructuring or cleanup finished
Milestone reached - A logical checkpoint in multi-step work
User explicitly requests - Via
```
/auto-commit
```
command or asking to commit

Commit Decision Criteria

Before committing, verify:

Changes are complete and functional (not work-in-progress)
No obvious errors or broken code being committed
Changes form a logical, cohesive unit of work
Sensitive files (.env, credentials, secrets) are NOT staged

Do NOT auto-commit when:

Changes are incomplete or experimental
User is actively iterating on the same files
Only whitespace or formatting changes
Uncertain about the scope of changes

Workflow

Step 1: Assess Changes

Run git status to see what changed:

git status

Review the changes to understand:

Which files were modified/added/deleted
Whether changes are related to a single feature/fix
If any sensitive files should be excluded

Step 2: Review Diff

Examine the actual changes:

git diff
git diff --staged

Understand the nature of changes to write an accurate commit message.

Step 3: Stage Relevant Files

Stage files selectively (preferred) or all changes:

# Preferred: Stage specific files
git add path/to/file1 path/to/file2

# Or stage all tracked changes
git add -u

# For new files that should be tracked
git add path/to/new/file

Never stage:

```
.env
```
files or any file containing secrets
```
node_modules/
```
,
```
__pycache__/
```
, or other dependency directories
Large binary files unless explicitly intended
IDE/editor configuration (
```
.idea/
```
,
```
.vscode/
```
unless project-shared)

Step 4: Craft Commit Message

Follow conventional commits format:

<type>(<scope>): <description>

[optional body with more details]

Co-Authored-By: Claude <noreply@anthropic.com>

Types:

```
feat
```
- New feature
```
fix
```
- Bug fix
```
docs
```
- Documentation only
```
style
```
- Formatting, no code change
```
refactor
```
- Code restructuring
```
test
```
- Adding/updating tests
```
chore
```
- Maintenance, dependencies, config

Examples:

feat(auth): implement user authentication with JWT

Add login/logout endpoints, JWT token generation, and middleware
for protected routes.

Co-Authored-By: Claude <noreply@anthropic.com>

fix(cart): resolve multi-vendor total calculation

Cart now correctly sums totals across different vendors
and applies shipping per vendor group.

Co-Authored-By: Claude <noreply@anthropic.com>

docs(prd): create Kuwait marketplace PRD

Comprehensive PRD covering multi-vendor marketplace requirements,
user stories, technical architecture, and MVP scope.

Co-Authored-By: Claude <noreply@anthropic.com>

Step 5: Commit

Create the commit using HEREDOC for proper formatting:

git commit -m "$(cat <<'EOF'
<type>(<scope>): <description>

<body if needed>

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

Step 6: Push to Remote

Push to the current branch:

git push

If the branch has no upstream:

git push -u origin <branch-name>

Step 7: Confirm Success

Verify the commit and push succeeded:

git status
git log -1 --oneline

Report to the user:

What was committed (files and summary)
Commit hash
Branch pushed to

Safety Rules

Never force push (
```
--force
```
or
```
-f
```
) without explicit user permission
Never commit secrets - Check for .env, API keys, passwords
Never amend previous commits unless explicitly requested
Always use Co-Authored-By to attribute Claude's contribution
Respect .gitignore - Don't stage ignored files
Check branch - Confirm you're on the expected branch before pushing

Proactive Usage

Claude should proactively invoke this skill when:

A task is marked complete and files were modified
User says "done", "finished", "complete" after implementation work
A logical milestone is reached in multi-step work
Creating or significantly updating documentation
After successful refactoring or bug fixes

Before auto-committing, briefly inform the user:

"I've completed [description]. Let me commit these changes."

Then proceed with the workflow unless the user objects.

Manual Invocation

Users can invoke via

/auto-commit

with optional arguments:

/auto-commit                    # Commit all staged/unstaged changes
/auto-commit "custom message"   # Use custom commit message
/auto-commit --dry-run          # Show what would be committed without committing