How do I install the Hotfix skill?

Run npx skillmds@latest add thettwe/hotfix in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Hotfix safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Hotfix?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Hotfix free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Hotfix?

thettwe (@thettwe) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Hotfix by thettwe — Agent Skill

Name: Hotfix
Author: thettwe

Hotfix

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.

thettwe ad36427 3.7 KB Updated Sep 17, 2026

File contents

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.

---name: hotfixdescription: 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.---# hotfixWraps `bin/hotfix.sh`. Creates the two branches a patch-releaseflow 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 tagBefore 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 slugAsk: "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 rejectanything else.## 3. Invoke```bin/hotfix.sh --target <cwd> --from <tag> --slug <slug> --checkout````--checkout` switches to the hotfix branch immediately. Skip itwhen the user has uncommitted work in the current branch (thescript will warn about a dirty tree if checkout fails — don'tlet it half-finish).## 4. Hand back the next-stepsThe output JSON includes a `next_steps[]` array with the exactcommands 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.

Frequently asked questions