From git-flow
Use this skill when the user asks an agent to create, switch, merge, validate, or manage Git branches using a safe Git Flow-inspired model with main as production and develop as the integration branch. Applies to feature, fix, hotfix, release, chore, refactor, test, and docs branch workflows.
How this skill is triggered — by the user, by Claude, or both
Slash command
/git-flow:branchThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this workflow whenever managing branches. Treat branch history as a shared
Use this workflow whenever managing branches. Treat branch history as a shared coordination system. Optimize for safety, explicit intent, and repository hygiene over speed or convenience.
main represents production-ready code only.develop is the primary development and integration branch.feature/*, fix/*, chore/*, refactor/*, test/*, and docs/*
branches start from develop.release/* branches start from develop.hotfix/* branches start from main.develop.release/* and hotfix/* branches merge into main and then back into
develop.feature/* for new functionality.fix/* for non-urgent bug fixes targeting development.hotfix/* for urgent production fixes from main.release/* for release preparation.chore/* for maintenance work.refactor/* for internal restructuring.test/* for test-only work.docs/* for documentation-only work.scripts/validate.py validates branch names, expected bases, and
allowed merge source/target combinations.references/checklist.md contains the required safety gates
for creation, switching, merging, release, and hotfix operations. Read it
before the first branch operation in a session and whenever a branch operation
is ambiguous.git status --short.git reset --hard, git clean,
git checkout --, git restore, forced branch deletion, or force push.Before creating, switching, or merging:
Run:
git status --short
git branch --show-current
Use gh for repository coordination context when helpful:
gh auth status
gh pr view <number> --json headRefName,baseRefName,state,title
gh issue view <number>
Do not mutate GitHub state unless the user explicitly asked for that action.
Verify all of the following:
If uncommitted changes exist, do not proceed with branch operations unless the user explicitly approves a precise plan that preserves those changes.
Branch names must use:
<type>/<short-description>
Rules:
// and -updates, changes, work, misc, or stuffExamples:
feature/add-user-session-timeout
fix/handle-empty-api-response
hotfix/patch-login-token-expiry
release/1.4.0
docs/update-api-auth-guide
Validate names before using them:
python3 scripts/validate.py name feature/add-user-session-timeout
python3 scripts/validate.py name release/1.4.0
Create branches only from the correct base:
feature/*, fix/*, chore/*, refactor/*, test/*, and docs/* from
developrelease/* from develophotfix/* from mainRequired sequence:
Run the required preflight.
Validate the requested branch name:
python3 scripts/validate.py name <branch>
Validate the required base:
python3 scripts/validate.py base <branch> <base>
Verify the base branch exists locally or remotely with explicit names:
git rev-parse --verify develop
git rev-parse --verify main
If the correct base does not exist, stop and report the issue.
If the working tree is dirty, stop unless the user approved a precise preservation plan.
Create the branch from the verified base with explicit branch names. Prefer the safest command available in the active environment.
Never merge without verifying source and target branches.
Allowed merge targets:
main: only from release/* or hotfix/*.develop: from completed work branches, release/*, or hotfix/*.Required sequence:
Run the required preflight.
Ensure the working tree is clean.
Verify source and target branches by exact name.
Validate the merge:
python3 scripts/validate.py merge <source> <target>
Confirm the source branch contains completed, coherent, reviewed, and validated work.
Merge one branch at a time.
If conflicts occur, stop. Report the conflicted files and the decision needed. Do not guess conflict resolutions.
release/<version>, for example release/1.4.0.develop.main.develop.hotfix/<short-description>.main.main.develop.develop from incomplete or unrelated work.npx claudepluginhub liljamesjohn-archive/codecave --plugin git-flowGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.