
Git Workflow
Follow step-by-step git workflows with your agent when preparing PRs, cleaning merged branches, resolving conflicts, or tagging monorepo releases.
Overview
Git Workflow is an agent skill most often used in Ship review (also Build pm, Operate iterate) that guides PR preparation, branch cleanup, conflict handling, and release tagging via structured git steps.
Install
npx skills add https://github.com/jezweb/claude-skills --skill git-workflowWhat is this skill?
- PR preparation checklist: log main..HEAD, diff stat, status, then title and body from real commit history
- gh pr create example with structured Summary and Test plan sections under 70-character titles
- Safe merged-branch cleanup on main with explicit excludes for main, master, and develop
- Guidance hooks for merge conflict resolution and monorepo tag/release patterns
- Marked claude-code-only compatibility in upstream metadata for structured git steps
- PR title guidance: under 70 characters
- PR prep step 1 uses git log main..HEAD --oneline plus git diff main...HEAD --stat
Adoption & trust: 809 installs on skills.sh; 841 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are solo-shipping from a feature branch and need a PR that matches the actual diff and history—not a vague summary you wrote from memory.
Who is it for?
Indie developers on GitHub who use gh CLI and want the agent to run the same PR prep sequence every time.
Skip if: Repos that forbid GitHub CLI or require enterprise-only merge bots without local git access, or work that has no git history yet.
When should I use this skill?
Asked to prepare a PR, clean branches, resolve merge conflicts, handle monorepo tags, or squash-and-merge patterns.
What do I get? / Deliverables
You get a pushed branch, a PR with summary and test plan derived from git log and diff stats, and optional follow-through on branch cleanup or tags.
- Opened or draft-ready PR with summary and test plan
- Cleaned-up local branch list after merges
- Release or monorepo tags when requested
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Pull request preparation and merge hygiene are Ship review activities even though the underlying commits were made during Build. Review subphase covers PR narrative, diff summarization, and pre-merge checks—the core triggers named in the skill description.
Where it fits
Turn a week of commits on a feature branch into a PR body that lists real changes and a test checklist.
Delete merged local branches after integrating work so a one-person repo stays navigable.
Apply monorepo tag patterns when you cut a patch release after a hotfix merge.
How it compares
Structured git and PR playbook—not a code review quality skill and not a hosted CI dashboard.
Common Questions / FAQ
Who is git-workflow for?
Solo builders and tiny teams using Claude Code (and similar agents) who want guided PR creation, branch hygiene, and release tagging without memorizing every git flag.
When should I use git-workflow?
Use it in Ship review when opening PRs; during Build pm when cleaning up long-lived branches; and in Operate iterate when tagging monorepo releases after fixes land.
Is git-workflow safe to install?
It expects git and optionally gh against your remotes; review the Security Audits panel on this page before letting an agent push or delete branches.
SKILL.md
READMESKILL.md - Git Workflow
# Git Workflow Guided workflows for common git operations that benefit from structured steps. ## PR Preparation When preparing a pull request: 1. **Gather context** - `git log main..HEAD --oneline` — list all commits on the branch - `git diff main...HEAD --stat` — see all changed files - `git status` — check for uncommitted work 2. **Draft PR content** - Title: under 70 chars, describes the change (not the branch name) - Body: summarise the "why", list key changes, add test plan - Use the commit history to write the summary — don't rely on memory 3. **Push and create** ```bash 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 )" ``` 4. **Verify** — `gh pr view --web` to open in browser ## Branch Cleanup Clean up merged branches safely: 1. **Switch to main and pull latest** ```bash git checkout main && git pull ``` 2. **List merged branches** (excludes main/master/develop) ```bash git branch --merged main | grep -vE '^\*|main|master|develop' ``` 3. **Delete local merged branches** ```bash git branch --merged main | grep -vE '^\*|main|master|develop' | xargs -r git branch -d ``` 4. **Prune remote tracking refs** ```bash git fetch --prune ``` 5. **List remote branches with no local tracking** (optional) ```bash git branch -r --merged origin/main | grep -vE 'main|master|develop|HEAD' ``` ## Merge Conflict Resolution When a PR has conflicts: 1. **Assess the conflict scope** ```bash git fetch origin git merge origin/main --no-commit --no-ff git diff --name-only --diff-filter=U # List conflicted files ``` 2. **For each conflicted file**, read the file and resolve: - Keep both changes if they're in different areas - If architecturally incompatible, prefer the main branch's approach and re-apply the PR's intent on top 3. **If rebase is cleaner** (few commits, no shared history): ```bash git rebase origin/main # Resolve conflicts per commit, then: git rebase --continue ``` 4. **If rebase is messy** (many conflicts, architectural divergence): - Abort: `git rebase --abort` or `git merge --abort` - Extract useful code: `git show origin/branch:path/to/file > /tmp/extracted.txt` - Apply changes manually to main - Close original PR with explanation 5. **Verify** — run tests, check the diff looks right ## Monorepo Release Tags In monorepos, scope tags to the package: ```bash # ❌ Ambiguous in monorepos git tag v2.1.0 # ✅ Scoped to package git tag contextbricks-v2.1.0 git push origin contextbricks-v2.1.0 ``` Pattern: `{package-name}-v{semver}` ## .gitignore-First Init When creating a new repo, always create `.gitignore` BEFORE the first `git add`: ```bash 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:** ```bash git rm -r --cached node_modules/ git commit -m "Remove node_modules from tracking" ``` ## Private Repo License Audit Before publishing or sharing a private repo: ```bash gh repo view --json visibility -q '.visibility' ``` If `PRIVATE`, ensure: - `LICENSE` contains proprietary notice (not MIT/Apache) - `package.json` has `"license": "UNLICENSED"` and `"private": true` - No `CONTRIBUTING.md` or "contributions welcome" in README