From melodic-software
Manages Git commit workflow using Conventional Commits format with safety protocols. Creates, validates, executes commits; handles hooks, PRs, and safety checks before operations.
npx claudepluginhub melodic-software/claude-code-plugins --plugin melodic-softwareThis skill is limited to using the following tools:
Comprehensive Git commit protocol implementing Conventional Commits specification with strict safety rules, proper attribution, and complete workflow guidance.
Creates git commits with repo detection, pre-commit checks, submodule support, and conventional messages. Activates on /commit or git commit requests.
Guides conventional commit messages, explicit git staging workflows, logical change grouping, and best practices with issue linking. Useful for git add, commit, or staging tasks.
Generates conventional commit messages by analyzing staged Git changes with AI, using prefixes like feat/fix. Ensures standardized format for Git workflows.
Share bugs, ideas, or general feedback.
Comprehensive Git commit protocol implementing Conventional Commits specification with strict safety rules, proper attribution, and complete workflow guidance.
This skill provides the authoritative protocol for all Git commit operations, including:
CRITICAL: This skill must be invoked before ANY commit operation to ensure compliance with safety protocols and message formatting requirements.
This skill should be used when:
gh pr createIMPORTANT: Only create commits when the user explicitly requests. If unclear, ask first.
These rules are non-negotiable and MUST be followed:
git push --force, git reset --hard, etc. unless explicitly requested--no-verify or --no-gpg-sign flags unless explicitly requested by usergit commit --amend - ONLY permitted when:
.env, credentials.json, etc. - warn user if requested-i flags (git rebase -i, git add -i) - not supported in non-interactive environmentsBefore executing any commit:
D:\repos\..., /home/user/...)All commit messages MUST follow the Conventional Commits specification with required Claude Code attribution.
<type>[optional scope]: <description>
[optional body]
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Use these standardized types:
Indicate breaking changes using EITHER:
feat!: change API response formatBREAKING CHANGE: <description> in message bodyAdd scope to provide context about what area of codebase is affected:
feat(api): add user authentication endpoint
fix(database): resolve connection timeout issue
docs(readme): update installation instructions
git commit -m "$(cat <<'EOF'
feat(auth): add JWT token refresh mechanism
Implements automatic token refresh to improve user experience
and reduce unnecessary re-authentication.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
Follow this complete workflow for every commit operation.
Run these commands in parallel to understand current state:
# View all staged and unstaged changes
git status
# See exact modifications (staged and unstaged)
git diff
git diff --staged
# Review recent commits to understand message style
git log --oneline -10
Why parallel: These are independent readonly operations - no dependencies between them.
Based on gathered information, first determine what to commit, then draft the message.
Count the files in each category from git status:
Working tree is clean - nothing to commit.
Exit gracefully. No commit needed.
Proceed directly to commit. User has already staged exactly what they want.
Ask user what to commit using AskUserQuestion:
"I see {N} modified file(s) but nothing is staged yet. What would you like to commit?"
Options:
1. "Stage and commit all modified files" → `git add -u` (stage all tracked files)
2. "Let me stage specific files first" → Exit, let user stage manually, then re-run /commit
If user chooses option 1, proceed with all modified files.
If user chooses option 2, exit and inform them to run git add <files> then /commit again.
Ask user using AskUserQuestion:
"I see {N} file(s) staged and {M} file(s) modified but not staged. What would you like to commit?"
Options:
1. "Commit only the staged files" → Proceed with staged files only
2. "Stage and commit everything" → `git add -u` then commit all
Respect user's choice.
After confirming what will be committed:
.env, credentials.json, API keys, tokensD:\repos\..., /home/user/... in committed contentMessage drafting checklist:
Run these commands in sequence (dependencies exist):
# Stage files if needed (based on Step 2 decision)
# - If user chose "stage all": git add -u
# - If files already staged: skip this step
# - If user is staging specific files: they should do this before running /commit
# Create commit with HEREDOC format (REQUIRED)
git commit -m "$(cat <<'EOF'
<type>[scope]: <description>
[optional body]
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
# Verify commit succeeded
git status
Why sequential: Each operation depends on the previous completing successfully.
CRITICAL: ALWAYS use HEREDOC format with $(cat <<'EOF' ... EOF) to ensure proper formatting and avoid shell escaping issues.
Staging commands reference:
git add -u - Stage all tracked modified files (doesn't include new untracked files)git add -A - Stage everything (tracked + untracked, modifications + deletions)git add <file> - Stage specific file(s)If commit fails due to pre-commit hooks (linters, formatters, etc.):
Retry ONCE if hook modified files:
# Check if files were modified by hook
git diff
# If modifications exist, check if safe to amend
git log -1 --format='%an %ae' # Check authorship (must be you)
git status # Check not pushed (must show "ahead of")
# If BOTH checks pass, amend the commit:
git add .
git commit --amend --no-edit
# If EITHER check fails, create NEW commit instead:
git add .
git commit -m "$(cat <<'EOF'
chore: apply automated linting fixes
Pre-commit hooks applied automatic formatting changes.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
Amend safety protocol:
git log -1 --format='%an %ae' - Only amend YOUR commitsgit status must show "Your branch is ahead" (not pushed to remote)When to skip retry:
When user requests pull request creation, follow this workflow.
# View current branch status
git status
# See all changes since divergence from base branch
git diff main...HEAD # Or other base branch
git log main...HEAD # All commits that will be in PR
# Check remote tracking status
git branch -vv
Review ALL commits that will be included in PR (NOT just the latest commit):
# Create new branch if needed
git checkout -b feature-branch-name
# Push to remote with tracking
git push -u origin feature-branch-name
# Create PR using HEREDOC for body
gh pr create --title "feat: Brief PR title" --body "$(cat <<'EOF'
## Summary
- Bullet point summary of changes
- Key features or fixes
- Breaking changes if any
## Test plan
- [ ] Manual testing steps
- [ ] Automated tests added/updated
- [ ] Documentation updated
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"
Return PR URL when complete so user can view it.
DO NOT push to remote unless user explicitly requests PR creation or push.
Only create commits when:
Do NOT commit when:
If unclear, ASK: "Would you like me to create a commit with these changes?"
CRITICAL REQUIREMENT: Before committing, verify all system-level changes are documented.
Any changes made outside this repository:
~/.gitconfig, ~/.ssh/config, etc.)Before executing commit:
SYSTEM-CHANGES.md has been updatedSee SYSTEM-CHANGES.md format requirements in repository documentation.
For concrete examples of common commit scenarios, see references/examples.md:
All examples follow Conventional Commits specification with required Claude Code attribution.
This skill includes comprehensive reference documentation:
For solutions to common Git commit issues, see references/troubleshooting.md:
All troubleshooting solutions follow safety protocols and never bypass hooks or GPG signing.
git diff and git status first.env, credentials.json to .gitignoreFor comprehensive test scenarios and multi-model testing guidance, see references/testing.md:
Current testing status: Verified with Sonnet. Haiku and Opus testing pending.
Date: 2025-11-28 Model: claude-opus-4-5-20251101