Agent-Skills.md

Agent Skills: Git Commit - Review, Fix, Commit & Deploy

Review project consistency and commit changes. Checks code vs docs alignment, updates CHANGELOG/README/DESIGN.md, updates ~/history.log, then commits and pushes. Use after finishing code modifications.

UncategorizedID: tsaol/awesome-claude/git-commit

Repository

tsaol/awesome-claude
tsaol
402

Install this agent skill to your local

pnpm dlx add-skill https://github.com/tsaol/awesome-claude/tree/HEAD/skills/git-commit

Skill Files

Browse the full folder contents for git-commit.

Download Skill

Loading file tree…

skills/git-commit/SKILL.md

Skill Metadata

Name
git-commit
Description
Review project consistency and commit changes. Checks code vs docs alignment, updates CHANGELOG/README/DESIGN.md, updates ~/history.log, bumps version, then commits, pushes, and deploys if configured. Use after finishing code modifications.

Git Commit - Review, Fix, Commit & Deploy

Overview

This skill reviews project consistency after code changes to ensure:

  • Code matches design documents
  • CHANGELOG is updated for new features/fixes
  • README reflects current functionality
  • No outdated documentation
  • ~/history.log is updated with session summary (if exists)
  • Version number is bumped appropriately
  • Deployment is triggered if configured in ~/.claude/collaboration.yml

When to Use

Trigger /git-commit after:

  • Completing a feature implementation
  • Fixing a bug
  • Before creating a PR
  • After significant code refactoring

Review Checklist

1. Code vs Design Docs

Check if implementation matches design:

  • Architecture follows design patterns
  • API endpoints match specification
  • Data models align with schema
# Find design docs
find . -name "DESIGN.md" -o -name "*.design.md" -o -name "design*.md"

2. CHANGELOG Update

Verify CHANGELOG.md includes:

  • New features added
  • Bugs fixed
  • Breaking changes noted
  • Version number updated (if applicable)
# Check recent changes vs CHANGELOG
git diff HEAD~5 --name-only
cat CHANGELOG.md | head -50

3. README Accuracy

Ensure README.md reflects:

  • Current installation steps
  • Updated usage examples
  • New CLI commands/options
  • Correct configuration
# Compare README with actual code
cat README.md

4. History Log Update

Check if ~/history.log exists and update it with session summary:

# Check if history.log exists
if [ -f ~/history.log ]; then
    echo "history.log exists, will update"
fi

If exists, append a summary of changes made in this session:

=== {DATE} {PROJECT_NAME} - {BRIEF_DESCRIPTION} ===

## Changes
- Feature/fix description
- Files modified
- PRs created

## Key Commands
- python hub/main.py search "query"
- etc.

5. Version Bump

Automatically detect and bump the project version before committing.

5a. Detect version file:

# Check common version file locations (in priority order)
[ -f package.json ] && echo "package.json"
[ -f pyproject.toml ] && echo "pyproject.toml"
[ -f setup.py ] && echo "setup.py"
[ -f setup.cfg ] && echo "setup.cfg"
[ -f VERSION ] && echo "VERSION"
[ -f version.txt ] && echo "version.txt"
[ -f Cargo.toml ] && echo "Cargo.toml"
[ -f build.gradle ] && echo "build.gradle"

5b. Determine bump type based on changes:

| Change Type | Bump | Examples | |-------------|------|----------| | Bug fix, typo, minor tweak | patch (0.0.x) | fix query bug, update docs typo | | New feature, enhancement | minor (0.x.0) | add user avatar upload, add new API endpoint | | Breaking change, major rewrite | major (x.0.0) | change API response format, remove deprecated endpoints |

Decision logic:

  1. Check git diff for breaking changes (removed public APIs, changed signatures, schema migrations)
  2. Check if new files/modules were added (likely minor)
  3. Default to patch if only modifications to existing files

5c. Bump the version:

# Python (pyproject.toml) - example: 0.2.1 → 0.2.2
# Read current version, calculate new version, update file
grep 'version = ' pyproject.toml

# Node.js (package.json) - example: 1.3.0 → 1.4.0
# Use npm version or manual edit
grep '"version"' package.json

# Plain VERSION file
cat VERSION

5d. Update CHANGELOG with new version header:

If CHANGELOG.md exists, ensure the new version appears at the top:

## [0.2.2] - 2026-02-26

- Fix slow query in user search
- Update error handling for API timeout

Important:

  • Always show the user the current version and proposed new version before bumping
  • If no version file exists, skip this step and note it in the report
  • Version bump changes are included in the same commit

6. Consistency Report

Generate a report:

## Consistency Check Report

### Files Changed
- [ ] List modified files

### Documentation Status
- [ ] CHANGELOG updated: Yes/No
- [ ] README accurate: Yes/No
- [ ] Design docs aligned: Yes/No
- [ ] ~/history.log updated: Yes/No/Not exists

### Version
- [ ] Version file detected: Yes (package.json) / No
- [ ] Current version: 0.2.1
- [ ] Bump type: patch / minor / major
- [ ] New version: 0.2.2

### Deploy Config
- [ ] Deploy configured: Yes/No
- [ ] Method: ssm / ssh / script / N/A
- [ ] Target: instance-id or host

### Issues Found
- Issue 1: ...
- Issue 2: ...

### Recommendations
- Action 1: ...
- Action 2: ...

Workflow

Code Changes Complete
        ↓
    /git-commit
        ↓
┌──────────────────────────────┐
│  1. Read changed files       │
│  2. Check CHANGELOG          │
│  3. Verify README            │
│  4. Compare with docs        │
│  5. Update ~/history.log     │
│  6. Version Bump             │
│  7. Generate report          │
│  8. Fix issues (if any)      │
│  9. Git commit & push        │
│ 10. Auto Deploy (if config)  │
└──────────────────────────────┘

Auto Commit

After fixing all issues, automatically commit and push:

  1. Stage changes: git add modified files
  2. Commit: Summarize code changes in simple, human-like message
  3. Push: Push to remote branch
  4. Create PR: If on feature branch, create PR with reviewer

Commit Message Style

ALWAYS use simple, human-like commit messages:

  • Keep messages short and natural
  • Summarize what the code changes actually do
  • Use casual, everyday language
  • Avoid formal conventions like "feat:", "chore:", "refactor:", etc.
  • Write like a human developer would in daily work
  • Never include any Claude-related attribution:
    • No "Generated with Claude Code"
    • No "Co-Authored-By: Claude"

Good examples:

  • add user login
  • fix slow queries
  • update packages
  • add image download to browser fetcher
  • store s3 paths in opensearch

Bad examples:

  • feat: implement comprehensive user authentication system with JWT token validation
  • chore: update dependencies to latest versions
  • docs: update CHANGELOG for feature xyz
# Example commit flow
git add .
git commit -m "add browser fetcher with screenshot support"
git push origin <branch>
gh pr create --reviewer tsaol  # if on feature branch

Auto Deploy

After a successful push, check if the project has deployment configured and trigger it.

Deploy Config

Deployment is configured per-project in ~/.claude/collaboration.yml:

projects:
  my-project:
    repo: user/my-project
    deploy:
      method: ssm           # Deployment method (ssm, ssh, script)
      instance: i-0abc123   # Target instance (for ssm/ssh)
      command: "cd /app && git pull origin main && sudo systemctl restart myapp"

Supported Deploy Methods

| Method | Description | Required Fields | |--------|-------------|-----------------| | ssm | AWS Systems Manager Run Command | instance, command | | ssh | SSH to remote server | host, user, command | | script | Run a local script | command |

Deploy Logic

Step 1: Check if deploy is configured

# Read collaboration.yml and find current project's deploy config
cat ~/.claude/collaboration.yml

Identify current project by matching git remote -v against the repo field in collaboration.yml.

Step 2: Check if deploy should trigger

Deploy ONLY when:

  • Current branch is main or master (direct push workflow)
  • OR a PR was just merged to main (github-flow workflow)
  • The push was successful

Do NOT deploy when:

  • On a feature branch (not yet merged)
  • Push failed
  • --no-deploy flag is used

Step 3: Confirm with user

🚀 Deploy detected for project "languages"
   Method: ssm
   Instance: i-0f86894d2231b1cd0
   Command: cd /home/ubuntu/languages && git pull origin main && sudo systemctl restart englearn

   Proceed with deployment? (y/n)

Always ask for confirmation before deploying. Never auto-deploy without user approval.

Step 4: Execute deployment

# SSM method
aws ssm send-command \
  --instance-ids "i-0abc123" \
  --document-name "AWS-RunShellScript" \
  --parameters "commands=[\"<deploy-command>\"]" \
  --output text

# SSH method
ssh user@host "<deploy-command>"

# Script method
bash -c "<deploy-command>"

Step 5: Verify deployment

# Check SSM command status
aws ssm list-command-invocations \
  --command-id "<command-id>" \
  --details \
  --output text

# Or check service status via SSM
aws ssm send-command \
  --instance-ids "i-0abc123" \
  --document-name "AWS-RunShellScript" \
  --parameters "commands=[\"systemctl status <service>\"]"

Step 6: Report deploy result

### Deploy Result
- Project: languages
- Method: ssm
- Instance: i-0f86894d2231b1cd0
- Status: ✅ SUCCESS / ❌ FAILED
- Details: Service restarted successfully

Usage

/git-commit              # Full consistency review + commit + deploy
/git-commit --quick      # Quick check (CHANGELOG + README only)
/git-commit --verbose    # Detailed report with suggestions
/git-commit --no-deploy  # Skip deployment even if configured

Example Output

## Git Check Report

### Changed Files (last commit)
- src/storage.py
- src/main.py

### CHANGELOG Status
⚠️  CHANGELOG.md not updated for recent changes

### README Status
✅ README.md is up to date

### Recommendations
1. Add entry to CHANGELOG.md:
   - "save url/source/category in sent_news.json"