Menu
Use when creating, switching, syncing, or cleaning up git branches. Enforces naming conventions and the branching flow.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Use before any code change — new feature, bug fix, refactor, or tech debt. Explores the problem, builds understanding through concrete artifacts, and produces a spec that gates the transition to execution.
Use when you have an approved spec from the Discover phase. Orchestrates implementation — parallel or serial — with autonomy and guardrails.
Use at the start of every conversation and when deciding how to approach a task. Routes to the appropriate phase of the Discover → Execute → Verify flow.
Use after execution is complete, before declaring work ready to ship. Unified verification through multiple lenses: correctness, code quality, review, and architectural feel.
Use at the start of a new conversation or when working in an unfamiliar codebase. Generates a ranked map of the repository structure to orient before diving into code.
Use when creating a git commit. Guides intelligent staging, conventional commit message authoring, and pre-commit validation.
| name | branch-management |
| description | Use when creating, switching, syncing, or cleaning up git branches. Enforces naming conventions and the branching flow. |
Manage branches following the project's branching model. Every branch operation should respect the flow: feat/fix → dev → rc → main.
git statusdev)git pull origin dev# Feature branch
git checkout -b feat/<description> dev
# Fix branch
git checkout -b fix/<description> dev
Follow the naming conventions from the git-conventions skill:
feat/<kebab-case> for featuresfix/<kebab-case> for bug fixesdev unless there's a specific reason not toIf the user hasn't specified a branch name, propose one based on the work description. Present it for confirmation:
I'll create
feat/add-vector-searchfromdev. Sound good?
Before switching:
git status# Stash if needed
git stash push -m "WIP: description of current work"
# Switch
git checkout <branch-name>
# Restore stash later
git stash pop
When dev has moved ahead and you need its changes:
git fetch origin
git rebase origin/dev
Prefer rebase over merge for feature branches — it keeps a linear history. If conflicts arise, resolve them carefully; don't discard changes without understanding them.
After a release lands on main:
git checkout dev
git merge main
git push origin dev
Or, if the project convention is to reset dev:
git checkout dev
git reset --hard origin/main
git push origin dev --force-with-lease
Always confirm with the user before force-pushing, even to dev.
Once a feature branch has been merged (via PR or locally):
# Delete local branch
git branch -d feat/<name>
# Delete remote branch
git push origin --delete feat/<name>
Find branches that have been deleted on the remote but still exist locally:
git fetch --prune
git branch -vv | grep ': gone]'
Present the list to the user before deleting anything. Never bulk-delete without confirmation.
A branch is likely stale if:
dev or mainList candidates and let the user decide.
Release candidate branches have special rules:
git checkout -b rc/X.Y.Z devX.Y.Z-rc.1, X.Y.Z-rc.2, etc.main or devmain — warn the user if they ask--force-with-lease instead of --force when force-pushing is necessarygit worktree list