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