| name | hotfix |
| description | Set up the branch topology for a patch release against a previously tagged version: ensures release/<major>.<minor> exists from the source tag, then creates hotfix/<slug> off it. TRIGGER when the user says "hotfix v1.0.0", "patch the release", "I need to fix something in the v2 line", "create a hotfix branch", "/nyann:hotfix". Match phrases like "fix this for the previous release" or "backport this fix to v1.0". Do NOT trigger on "fix this bug" without a target tag — that's a regular feature branch via `/nyann:branch fix <slug>`. Do NOT trigger on "release a hotfix" if the user already has the branch set up — they're after `/nyann:release` directly.
|
hotfix
Wraps bin/hotfix.sh. Creates the two branches a patch-release
flow needs:
release/<major>.<minor> — long-lived, branched from the source
tag. Idempotent: reused if it already exists. Future patches on
the same minor go on the same branch.hotfix/<slug> — short-lived, branched off the release branch.
The user commits the actual fix here.
After this skill: the user makes the fix, commits, then runs
/nyann:release from the hotfix branch.
1. Resolve the source tag
Before invoking, confirm the source tag with the user:
- "I want to patch v1.2.0" →
--from v1.2.0.
- "I want to fix something in the previous minor" → ask which tag
exactly.
- If they said "patch the latest release" without naming a tag,
list
git tag --sort=-v:refname | head -5 and ask.
2. Pick a slug
Ask: "what's the change?" Convert their answer to a slug:
- "Fix the broken auth callback" →
fix-auth-callback
- "Patch the SQLi in the user-search endpoint" →
patch-sqli-user-search
The script enforces lowercase + alphanumeric + hyphen; it'll reject
anything else.
3. Invoke
bin/hotfix.sh --target <cwd> --from <tag> --slug <slug> --checkout
--checkout switches to the hotfix branch immediately. Skip it
when the user has uncommitted work in the current branch (the
script will warn about a dirty tree if checkout fails — don't
let it half-finish).
4. Hand back the next-steps
The output JSON includes a next_steps[] array with the exact
commands to run next:
- (skip if --checkout was used)
git checkout hotfix/<slug>
- Make the fix, commit it (use
/nyann:commit for a
Conventional Commits message).
- Merge the hotfix into the release branch:
git checkout release/<m>.<n> && git merge --no-ff hotfix/<slug>.
- Run
/nyann:release --version <patch> --push from the release
branch. The script suggests the patch version (source-tag + 1 in
the patch slot) — confirm with the user before passing it through.
release.sh operates on the current branch (HEAD), so the merge
step in (3) is what puts the right commits on the lineage that
gets tagged.
5. After the release
- The release tag (e.g.
v1.2.4) is added on release/1.2.
- The release branch should be merged back into
main so the fix
isn't lost on the next minor cut. nyann doesn't do this for the
user; suggest git checkout main && git merge --no-ff release/1.2 && git push.
- Consider deleting the
hotfix/<slug> branch via
/nyann:cleanup-branches once the merge lands.
When to hand off
- "Just create a feature branch" →
/nyann:branch fix <slug> (no
release-branch ceremony).
- "I already have the hotfix branch — just release it" → merge it
into the release branch first (
git checkout <release> && git merge --no-ff <hotfix>), then /nyann:release --version <patch>
from that branch.
- "Pre-release, not patch" →
/nyann:release --version <stable>-rc.1
on the regular feature branch; release.sh's prerelease detection
handles it.
