new-branch

name

new-branch

description

Create a strategy-compliant git branch. TRIGGER when the user says "create a branch for X", "start a feature branch", "new fix branch", "cut a release branch", "start a hotfix", "branch for bug in Y", "make a branch named X", "/nyann:branch". DISAMBIGUATION: if the user mentions BOTH branch creation AND committing in the same message (e.g. "branch and commit", "start a branch and commit this"), this skill wins — create the branch first, then suggest `/nyann:commit` (or the commit skill) as the follow-up. Do NOT trigger on informational questions about branches ("what branch am I on?") or on general git-history questions.

new-branch

You are creating a git branch that matches the repo's active profile. Never run git branch or git checkout -b directly — route through bin/new-branch.sh so the branching strategy, base branch, and name pattern stay consistent.

1. Infer purpose

Read the user's phrasing. Purpose inference:

User says something like...	Purpose
"new feature for X", "landing page", "add X"	feature
"bug in checkout", "fix Y", "bugfix"	bugfix
"release v1.2", "cut a release"	release
"hotfix production", "emergency fix"	hotfix

If the phrasing is ambiguous ("I want a branch for the auth work"), you MUST call the AskUserQuestion tool (not plain text):

{
  "questions": [
    {
      "question": "What kind of branch do you need?",
      "header": "Purpose",
      "multiSelect": false,
      "options": [
        { "label": "Feature", "description": "New functionality or enhancement" },
        { "label": "Bugfix", "description": "Fix for an existing issue" },
        { "label": "Release", "description": "Cut a release branch" },
        { "label": "Hotfix", "description": "Emergency fix against a tagged version" }
      ]
    }
  ]
}

Don't guess when stakes are non-trivial (release vs hotfix especially).

2. Derive a slug

Short, lowercase-kebab, no spaces. Map the user's words:

• "bug in the checkout button" → checkout-button
• "add a landing page" → landing-page
• "v1.2.0" release → slug is 1.2.0, use --version 1.2.0 (see below).

Enforce the regex ^[a-z0-9][a-z0-9._-]*$. If the user's phrasing doesn't reduce to a clean slug, propose one and ask for confirmation.

3. Release / hotfix version flag

release and hotfix patterns in GitFlow use {version} not {slug}. For those purposes, ask the user which version (unless they already said), then pass --version <x.y.z> to the orchestrator.

4. Invoke the orchestrator

bin/new-branch.sh \
  --target <cwd> \
  --profile <active-profile-name> \
  --purpose <feature|bugfix|release|hotfix> \
  --slug <slug> \
  [--version <x.y.z>] \
  --checkout

Exit codes you should expect:

Code	Meaning	What to do
0	created (and checked out if --checkout)	Report the new branch name
2	profile not found	Ask user to run bootstrap, or pick a different profile
3	purpose not supported by strategy / placeholder left	Tell user (e.g. GitHub Flow has no release)
4	slug invalid	Tell user + proposed fix
5	branch already exists, no --checkout	Offer to switch or suggest a different slug

5. Report

On success, print:

• The new branch name.
• The base branch it was created from.
• One-line "next step" suggestion (e.g. "start making your changes, then run /nyann:commit").

When something goes wrong

• Strategy doesn't support the purpose (e.g. GitHub Flow + release) → tell the user; suggest creating a release tag instead if that's their intent.
• main/master doesn't resolve → the repo wasn't bootstrapped; run /nyann:bootstrap first to seed.
• Slug collision on a prior PR → suggest -v2 or a more specific slug rather than silently appending.

When to hand off

• "Now commit my changes" → commit skill.
• "Open a PR from this branch" → pr skill (PR only) or ship skill (PR + merge).
• "Sync this branch with main" → sync skill.