Git Operations Skill

This skill provides comprehensive git repository information for commits, PRs, and general repository status.

Important: User Confirmation Required

ALWAYS ask for user confirmation before:

• Creating commits (git commit)
• Pushing to remote (git push)
• Creating pull requests (which includes pushing)

Use the AskUserQuestion tool to present the proposed action and get explicit approval before executing.

These operations can be performed without confirmation:

• Reading repository status (git status, git diff, git log, etc.)
• Staging files (git add)
• Creating/switching branches (git branch, git checkout)
• Fetching from remote (git fetch)
• All other read-only or local-only git operations

Instructions

Follow these steps to gather and present git information:

1. Basic Repository Status

git status

This shows:

• Current branch name
• Tracking status (ahead/behind remote)
• Staged files (green)
• Unstaged files (red)
• Untracked files

2. Staged Changes (Ready for Commit)

git diff --cached --stat

Shows statistics of staged files.

git diff --cached

Shows full diff of what would be committed.

Present: Summarize the number of staged files and the nature of changes.

3. Unstaged Changes (Modified but Not Staged)

git diff --stat

Shows statistics of modified but unstaged files.

git diff

Shows full diff of unstaged changes.

Present: List files with unstaged modifications.

4. Creating Commits

When the user asks to create a commit:

1. Gather information about changes:

   • Check what files would be committed
   • Review the diffs to understand the changes
   • Check recent commit history for message style: git log --oneline -10

2. Draft commit message based on recent history style:

   • Keep it 1-2 sentences maximum
   • Focus on "why" not "what"
   • Follow the repository's commit message style

3. Ask for confirmation using AskUserQuestion tool:

   • Present the proposed commit message
   • Show what files will be committed
   • Warn about sensitive files (.env, credentials.json, etc.) if present
   • Ask user to approve, modify, or cancel

4. If approved, create the commit:

   • If user said "commit all" or similar: stage everything with git add . first
   • Otherwise only commit staged changes
   • Create the commit: git commit -m "Your concise commit message"

Important rules:

• ALWAYS ask for confirmation before committing using the AskUserQuestion tool
• ALWAYS create NEW commits, NEVER use --amend
• If nothing staged and not staging all, inform user (don't create empty commit)
• User must explicitly approve the commit before executing it

5. Recent Commit History

git log --oneline -10

Shows last 10 commits for context on commit message style.

6. Branch Comparison (For PR Context)

Show changes since branching:

git diff main...HEAD --stat

Statistics of all changes from base branch.

git log main..HEAD --oneline

All commits that would be in a PR.

git diff main...HEAD

Full diff for PR review (use sparingly, can be large).

7. Remote Status

git rev-list --left-right --count HEAD...@{upstream} 2>/dev/null || echo "No upstream configured"

Shows how many commits ahead/behind the remote.

8. Creating Pull Requests with gh CLI

When the user asks to create a PR, follow these steps:

1. Verify branch status:

git branch --show-current
git status

• If on main/master, warn user and don't create PR
• Check if branch needs to be pushed

2. Understand the full scope of changes from when the branch diverged:

git log origin/main...HEAD --oneline
git diff origin/main...HEAD --stat
git diff origin/main

• If no commits ahead of default branch, inform user

3. Draft PR title and description based on all changes:

   • Analyze ALL commits and the full diff, not just the latest commit
   • Draft a concise title (50 chars or less)
   • Create a detailed summary with:
     • What was changed and why
     • Major changes as bullet points
     • Focus on "why" and user impact

4. Ask for confirmation using AskUserQuestion tool:

   • Present the proposed PR title and description
   • Show summary of files changed and commits included
   • Confirm that user wants to push (if needed) and create PR
   • Allow user to approve, modify, or cancel

5. If approved, push to remote if needed:

git push -u origin $(git branch --show-current)

6. Create PR with gh CLI:

gh pr create --title "Concise title (50 chars or less)" --body "$(cat <<'EOF'
## Summary

Detailed explanation of the major changes, what was modified, and why.
Analyze ALL commits and the full diff, not just the latest commit.

- Major change 1
- Major change 2
- etc.

Focus on the "why" and user impact, not just the "what".
EOF
)"

7. Return the PR URL when done

Important notes:

• ALWAYS ask for confirmation before pushing and creating PR using the AskUserQuestion tool
• Analyze ALL commits that will be included, not just the latest one
• Use HEREDOC format for the body to ensure proper formatting
• Do NOT use the Task or TodoWrite tools when creating PRs
• Adapt base branch name (try main, master, origin/main, etc.)
• User must explicitly approve before pushing to remote

Presenting Information

Organize your response based on what the user needs:

For Commit Questions

• Staged files: List files ready to commit with brief summary
• Commit message suggestion: Based on changes and recent history
• Warnings: Flag any concerns (large files, potential secrets)

For PR Questions

• Branch comparison: Summarize all changes since base branch
• Commit list: Show commits that would be included
• Files changed: List all modified files with stats
• Create PR: Use gh pr create to create the PR with appropriate title and description
• PR description template: If only describing, suggest title and description

For General Status

• Current state: Branch name, tracking status
• Staged vs unstaged: Clear breakdown of what's where
• Next steps: Actionable suggestions

Best Practices

1. Be concise: The user is experienced, provide summaries not explanations
2. Adapt base branch: Try main, master, develop as needed
3. Handle errors gracefully: Not all repos have remotes or follow conventions
4. Skip noise: Ignore lock files, build artifacts in summaries
5. Security awareness: Flag potential secrets or sensitive files

Examples

Example 1: Commit message for staged changes

User: "Write a commit message"

git diff --cached --stat
git diff --cached
git log --oneline -10

Response:

Staged: 3 files (parser.py, test_parser.py, README.md)

Suggested commit message:
"Add config parser with tests and documentation"

Example 2: Commit message for unstaged changes

User: "Commit my changes"

git status
git diff --stat
git diff
git log --oneline -10

Draft commit message based on changes, then ask for confirmation:

• Use AskUserQuestion to present: "Add config parser with tests"
• Show files that will be committed
• After approval, stage and commit:

git add -u
git commit -m "Add config parser with tests"

Example 3: PR description for branch

User: "Write a PR description"

git log main..HEAD --oneline
git diff main...HEAD --stat
git diff main...HEAD

Response:

**Add configuration parser with validation**

Implements config parsing and validation system.

- Added parse_config() for YAML/JSON parsing
- Added validate_config() with schema validation
- Full test coverage for both modules
- Updated docs with examples

6 files changed: +365 -8