/hotfix

name: hotfix
description: "Emergency fix bypassing normal sprint process — hotfix branch, approvals tracked, backport verified, full audit trail."
argument-hint: "[bug-id or description]"
user-invocable: true
disable-model-invocation: true
allowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion, Bash(git rev-parse *), Bash(git tag --list*), Bash(git branch --list *)
model: sonnet

Hotfix

> **Explicit invocation only**: This skill should only run when the user explicitly requests it with `/hotfix`. Do not auto-invoke based on context matching.

Phase 1: Assess Severity

Read the bug description or ID. Assess severity on `/bug-triage`'s scale:

• **S1 (Critical)**: Crash, data loss, or complete feature failure — the game cannot proceed (rate a security issue by that impact)
• **S2 (High)**: Major feature broken, but the game is still playable
• **S3 or lower**: Feature degraded with a workaround, or cosmetic — normal bug fix workflow applies

Confirm with `AskUserQuestion`:

• Prompt: "I've assessed this as **[assessed severity]** — [brief rationale]. Confirm severity to proceed:"
• Options:
• `[A] S1 (Critical) — crash, data loss, or complete feature failure`
• `[B] S2 (High) — major feature broken, game still playable`
• `[C] S3 or lower — redirect to normal bug fix workflow`

If [C]: stop. Verdict: **REDIRECTED** — use the normal bug fix workflow for S3 and below.

---

Phase 2: Create Hotfix Record

Draft the hotfix record:

## Hotfix: [Short Description]
Date: [Date]
Severity: [S1/S2]
Reporter: [Who found it]
Status: IN PROGRESS

### Problem
[Clear description of what is broken and the player impact]

### Root Cause
[To be filled during investigation]

### Fix
[To be filled during implementation]

### Testing
[What was tested and how]

### Approvals
- [ ] Fix reviewed by lead-programmer
- [ ] Regression test passed (qa-tester)
- [ ] Release approved (producer)

### Rollback Plan
[How to revert if the fix causes new issues]

Ask: "May I write this to `production/hotfixes/hotfix-[date]-[short-name].md`?"

If yes, write the file, creating the directory if needed.

---

Phase 3: Create Hotfix Branch

Check whether this is a git repository:

`Bash: git rev-parse --is-inside-work-tree 2>/dev/null`

If this command fails or returns empty: note "Not a git repository — create the branch manually." and skip branch creation.

`[base-ref]` is the release the bug is in. Releases are tags on `main` (the trunk), so it is that release's tag (`git tag --list`; the newest is usually the live build) — or its `release/*` branch, if one was cut to stabilise that release (`git branch --list 'release/*'`). Never the head of `main`: it may carry work that has not shipped.

If the check passes, use `AskUserQuestion` before creating the branch:

• Prompt: "Ready to create hotfix branch 'hotfix/[short-name]' from [base-ref]?"
• Options:
• `[A] Yes — create branch`
• `[B] Use a different base ref — I'll specify it`
• `[C] Skip — I'll create the branch myself`

Only run `git checkout -b hotfix/[short-name] [base-ref]` if user selects [A]. If [B]: ask the user for the base ref, then run the command with that ref. If [C]: skip branch creation and proceed to Phase 4.

---

Phase 4: Investigate and Propose

Find the root cause. Draft the minimal fix: which files change, what the change does, and what it deliberately leaves alone. Do NOT refactor, clean up, or add features alongside the hotfix.

Present the root cause and proposed fix, then ask: "May I implement this fix?" Do not modify any code before this approval — an emergency flow earns its audit trail by approving the change *before* it exists, not after.

---

Phase 4b: Implement (only after approval)

Implement the approved minimal change. Validate the fix by running targeted tests for the affected system, with `commands.test` from `project.yaml` (narrowed to the affected suite where the runner allows) — never a runner line written from memory, which drops the flags the engine needs (gdUnit4 hangs without `--remote-debug tcp://127.0.0.1:0`). Check for regressions in adjacent systems. If `commands.test` is unset, or no test covers the affected system, say so and record `Tests: NOT RUN — [reason]` in the hotfix record's Testing section; the Phase 5b QA gate then carries the verification.

Update the hotfix record with root cause, fix details, and test results.

---

Phase 5: Collect Approvals

Use the `Agent` tool to request sign-off in parallel:

• `subagent_type: lead-programmer` — Review the fix for correctness and side effects
• `subagent_type: qa-tester` — Run targeted regression tests on the affected system
• `subagent_type: producer` — Approve deployment timing and communication plan

All three must return APPROVE before proceeding. If any returns CONCERNS or REJECT, do not deploy — surface the issue and resolve it first.

---

Phase 5b: QA Re-Entry Gate

After approvals, determine the QA scope required before deploying the hotfix. Spawn `qa-lead` via `Agent` with:

• The hotfix description and affected system
• The regression test results from Phase 5
• A list of all systems that touch the changed files (use Grep to find callers)

Ask qa-lead: **Is a full smoke check sufficient, or does this fix require a targeted team-qa pass?**

Apply the verdict:

• **Smoke check sufficient** — run `/smoke-check` against the hotfix build. If PASS or

PASS WITH WARNINGS, proceed to Phase 6 (carry the warnings into the hotfix record). If **FAIL**, do not deploy: return to Phase 4 with the failing checks, get the revised fix approved there, implement it (Phase 4b), then re-run Phase 5's approvals — qa-tester's regression run among them — and this QA step. A hotfix that breaks the smoke suite is a second incident, not a fix.

• **Targeted QA pass required** — run `/team-qa feature: [affected-system]` scoped to the changed system only. If QA returns APPROVED or APPROVED WITH CONDITIONS, proceed to