hotfixlisted

# 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 t