git

name	git
version	1.0.0
description	Git operations — branch, commit, push, merge
uses	[]
requires	{"tools":["git"],"env":[]}
security	{"risk_level":"write","capabilities":["git:read","git:write"],"requires_approval":false}

Git Operations

Interact with git version control — branching, committing, pushing, and merging. This skill provides structured access to git operations with safety guardrails.

Execution Model

This is a builtin skill (handler: type: builtin). When any git_* tool is invoked, the executor runs the corresponding git command in the workspace directory. The tool schema in tool.yaml defines the external contract; the executor handles the git operations directly.

When to Use

• Checking repository status before or after changes
• Creating feature branches for new work
• Staging and committing changes
• Pushing branches to remote
• Viewing commit history to follow conventions
• Switching between branches

Methodology

1. Before Starting Work

Always start with a clean state:

1. Check current branch (git_status) — ensure you're not on main
2. Pull latest if on main (git pull)
3. Create a feature branch if starting new work

2. Branch Naming

Follow conventional naming: <type>/<description>

Prefix	Use For
feat/	New features
fix/	Bug fixes
docs/	Documentation
refactor/	Code refactoring
test/	Test additions or changes

3. Staging Changes

Always stage specific files — never use git add . or git add -A:

• Review what's changed with git_diff
• Stage only the files that belong in this commit
• Verify staged changes with git_diff(staged=true)

4. Committing

Use conventional commit format: type(scope): description

• Keep the first line under 72 characters
• Add a blank line then longer explanation if needed
• Reference issues with #N

5. Pushing

• Push with upstream tracking on first push
• Never force push to shared branches
• Verify push succeeded

Output Format

## Git Operation

- Operation: [status/diff/log/branch/commit/push]
- Result: [output summary]
- Branch: [current branch]
- Clean: [yes/no]

Quality Criteria

• Working on a feature branch, not main
• Changes are staged specifically (not git add .)
• Commit messages follow conventional format
• No force pushes to shared branches
• Tests pass before committing
• Working directory state is understood before committing

Common Mistakes

• Committing to main directly: Always work on a feature branch. Direct commits to main bypass review.
• Using git add . or git add -A: This stages everything including secrets, build artifacts, and unrelated changes. Stage specific files.
• Force pushing to shared branches: This rewrites history that others may have pulled. Never force push to main or shared branches.
• Not checking status before committing: Committing without reviewing what's staged leads to accidental commits of wrong files.
• Missing conventional commit format: Using vague messages like "fix stuff" instead of fix(auth): handle expired token refresh. Follow the project's commit conventions.
• Not pulling before starting work: Starting on a stale branch leads to merge conflicts. Always pull main before creating a feature branch.

Completion

A git operation is complete when:

• The intended operation succeeded (commit created, branch switched, etc.)
• Working directory is in the expected state
• No unintended side effects (wrong files staged, wrong branch, etc.)