new-branch — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited new-branch (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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.
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).
Short, lowercase-kebab, no spaces. Map the user's words:
checkout-buttonlanding-page1.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.
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.
bin/new-branch.sh \
--target <cwd> \
--profile <active-profile-name> \
--purpose <feature|bugfix|release|hotfix> \
--slug <slug> \
[--version <x.y.z>] \
--checkoutExit 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 |
On success, print:
run /nyann:commit").
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.
-v2 or a more specific slugrather than silently appending.
commit skill.pr skill (PR only) or ship skill(PR + merge).
sync skill.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.