/hotfix

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:

1. `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. 2. `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:

1. (skip if --checkout was used) `git checkout hotfix/<slug>` 2. Make the fix, commit it (use `/nyann:commit` for a Conventional Commits message). 3. Merge the hotfix into the release branch: `git checkout release/<m>.<n> && git merge --no-ff hotfix/<slug>`. 4. 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.