Skip to content
Back to skills

New Branch

ASecurity

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 th...

  • 6 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added May 26, 2026
devopsgogit

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add thettwe/nyann --skill new-branch --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of New Branch?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for New Branch
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/thettwe-new-branch/badge)](https://www.skillsdirectory.com/skills/thettwe-new-branch)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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):

```json
{
  "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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.