Guided git workflows: prepare PRs, clean up branches, resolve merge conflicts, handle monorepo tags, squash-and-merge patterns. Use when asked to prepare a PR, clean branches, resolve conflicts, or tag a release.
72
91%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Guided workflows for common git operations that benefit from structured steps.
When preparing a pull request:
Gather context
git log main..HEAD --oneline — list all commits on the branchgit diff main...HEAD --stat — see all changed filesgit status — check for uncommitted workDraft PR content
Push and create
git push -u origin HEAD
gh pr create --title "..." --body "$(cat <<'EOF'
## Summary
- ...
## Test plan
- [ ] ...
🤖 Generated with [Claude Code](https://claude.com/claude-code)
EOF
)"Verify — gh pr view --web to open in browser
Clean up merged branches safely:
Switch to main and pull latest
git checkout main && git pullList merged branches (excludes main/master/develop)
git branch --merged main | grep -vE '^\*|main|master|develop'Delete local merged branches
git branch --merged main | grep -vE '^\*|main|master|develop' | xargs -r git branch -dPrune remote tracking refs
git fetch --pruneList remote branches with no local tracking (optional)
git branch -r --merged origin/main | grep -vE 'main|master|develop|HEAD'When a PR has conflicts:
Assess the conflict scope
git fetch origin
git merge origin/main --no-commit --no-ff
git diff --name-only --diff-filter=U # List conflicted filesFor each conflicted file, read the file and resolve:
If rebase is cleaner (few commits, no shared history):
git rebase origin/main
# Resolve conflicts per commit, then:
git rebase --continueIf rebase is messy (many conflicts, architectural divergence):
git rebase --abort or git merge --abortgit show origin/branch:path/to/file > /tmp/extracted.txtVerify — run tests, check the diff looks right
In monorepos, scope tags to the package:
# ❌ Ambiguous in monorepos
git tag v2.1.0
# ✅ Scoped to package
git tag contextbricks-v2.1.0
git push origin contextbricks-v2.1.0Pattern: {package-name}-v{semver}
When creating a new repo, always create .gitignore BEFORE the first git add:
cat > .gitignore << 'EOF'
node_modules/
.wrangler/
dist/
.dev.vars
*.log
.DS_Store
.env
.env.local
EOF
git init && git add . && git commit -m "Initial commit"If node_modules is already tracked:
git rm -r --cached node_modules/
git commit -m "Remove node_modules from tracking"Before publishing or sharing a private repo:
gh repo view --json visibility -q '.visibility'If PRIVATE, ensure:
LICENSE contains proprietary notice (not MIT/Apache)package.json has "license": "UNLICENSED" and "private": trueCONTRIBUTING.md or "contributions welcome" in READMEee91a87
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.