new-branchlisted
Install: claude install-skill thettwe/nyann
# 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