New Branch

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:

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:

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.