Menu
Use when the user asks to create, make, or start a new branch (e.g. `/branch`), or wants a conventional-commit-style branch name generated from the current work.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | branch |
| description | Use when the user asks to create, make, or start a new branch (e.g. `/branch`), or wants a conventional-commit-style branch name generated from the current work. |
Create a new branch off the default branch with a conventional-commit-style name, derived from the conversation or uncommitted changes.
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@'. If empty, fall back to whichever of main or master exists as a local branch (git branch --list), preferring main.git branch --show-current.git status --short and git diff --stat (plus --cached --stat if staged), then summarize the changes (1-2 sentences).Format: {type}/{short-kebab-description}
Type is one of the conventional-commit prefixes: feat fix chore refactor docs test perf ci.
Rules: lowercase kebab-case, 2-4 words, hyphens only — e.g. feat/ai-event-handler, fix/null-guard-context-args, chore/update-lockfile.
If the user gave an explicit name, use it as-is (skip analysis).
Run git checkout -b {branch-name} and confirm. Keep the whole flow quick — this is a utility, not an investigation.
Use when the user explicitly runs /setup-precommit to install or refresh a quiet, staged-only git pre-commit hook (secretlint → oxlint → oxfmt) wired through package.json "prepare". User-invoked command only, never auto-triggered.
Use when auditing or improving an agent skill package before it ships or is handed off.
Use when the user is working on their own PR — drafting/creating it, handling reviewer comments, verifying fixes, or requesting re-review.
Use when reviewing someone else's PR at any stage of the review lifecycle — digest a PR, write a review, or verify follow-up changes.
Use when fixing a bug, refactoring existing code without changing its behavior, or adding a feature that extends existing behavior — any code change that needs a verifiable foundation before the change is made.
Use when the user wants to A/B test prompts or workflows, validate behavioral equivalence, or stress-test non-deterministic outputs at scale via repeated multi-agent runs.