From cape
Use this skill whenever the user wants to CREATE or SET UP a new git branch. This includes any request to generate a branch name, start a new branch, check out a fresh branch, or begin work that requires branching. Covers explicit requests ("create a branch", "new branch", "branch for this") and implicit ones ("set up a branch for X", "start working on X" when no branch exists). Also applies to `/cape:branch`. Do NOT use for operations on existing branches: switching, deleting, listing, rebasing, merging, pushing, or comparing branches.
npx claudepluginhub sqve/cape --plugin capeThis skill uses the workspace's default tool permissions.
<skill_overview> Generate a well-formatted git branch name from session context and create it. Pulls
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
<skill_overview> Generate a well-formatted git branch name from session context and create it. Pulls context from active br tasks, conversation history, and user input to build a descriptive branch name without interrogating the user. </skill_overview>
<rigidity_level> MEDIUM FREEDOM — Adapt naming format to user preferences and project conventions. The rigid rules: verify git repo, confirm before creating, check for existing branch, warn on uncommitted changes. </rigidity_level>
<when_to_use>
Don't use for:
<critical_rules>
git checkout -b</critical_rules>
<the_process>
Check git state:
cape git context
If not in a git repo, stop and tell the user. If there are uncommitted changes, warn but don't block.
Check for active br task context:
br list --status in_progress 2>/dev/null
If a br task is active, use its title and type to inform the branch name. If multiple tasks are in-progress, prefer the most recently updated one, or ask the user which task the branch is for. If the user referenced a specific task, look it up. Otherwise, infer from the conversation what the work is about.
Build the name from two parts: prefix and description.
Prefix — derive from the nature of the work:
| Prefix | When to use |
|---|---|
feat/ | New features and functionality |
fix/ | Bug fixes |
chore/ | Maintenance, config, dependencies |
refactor/ | Restructuring without behavior change |
docs/ | Documentation changes |
test/ | Test-only changes |
Description — kebab-case, 2-5 words summarizing the work. When a br task provides context, derive the description from the task title rather than embedding the task ID in the branch name.
Examples:
feat/add-branch-skill (from br task "Skill: branch")fix/resolve-auth-timeoutchore/update-dependenciesAfter building the name, validate it:
cape git validate-branch <name>
If validation fails, parse the error, adjust the name, and re-validate before presenting. If re-validation still fails, show the error and ask the user to provide or adjust the name.
Present the validated name to the user. Once approved (or after applying their edits):
cape git create-branch <branch-name>
If creation fails (existing branch, bad ref format, missing prefix), show the errors and ask: fix the name, pick a different name, or abort.
</the_process>
User has an active br taskbr task cape-2vo.2 ("Skill: branch") is in_progress.
Generated: feat/add-branch-skill
Description derived from task title. No task ID in the branch name.
User says "looks good" → git checkout -b feat/add-branch-skill
User: "Create a branch for fixing the login timeout bug"
Generated: fix/login-timeout
Prefix inferred from "fixing". Description summarizes the work.
Branch already existsGenerated name feat/add-oauth already exists.
Response: "Branch feat/add-oauth already exists. Switch to it, pick a different name, or
abort?"
<key_principles>
</key_principles>