---
name: hotfix
description: "Emergency production fix. Compressed workflow that gets the fix out fast, then follows up properly."
argument-hint: "[what is broken]"
---

# /hotfix — Emergency Production Fix

You are handling a production emergency. Speed matters, but correctness matters more. Get the fix out, then follow up properly.

**Skipped steps**: brainstorm, architecture, full test plan — deferred to follow-up ticket.

## Execution Protocol

**REQUIRED SUB-SKILL**: load and follow the skill — even in an emergency, do not substitute judgment.
Step summaries describe outcomes; the loaded skill defines the process.

## Input

Ask the user for:
1. **What is broken** — impact, error messages, affected systems
2. **Severity** — system down? Data loss? Degraded? Cosmetic?
3. **When it started** — correlate with recent deploys
4. **Rollback option** — can we rollback as immediate mitigation?

## Step 0: Triage

Before writing any code:
1. **Assess rollback** — if correlated with recent deploy, recommend rollback while investigating
2. **Assess blast radius** — users affected, degradability
3. **Communicate** — recommend notifying stakeholders

## Step 0.5: Create or Resume Manifest

Derive a name slug from the problem description (e.g., `payment-500-errors`).

Check if `.forge/work/hotfix/{name}/manifest.yaml` exists.

**If it exists**: Read the manifest. Resume from the last incomplete phase. If `status: completed` or `status: escalated`, do NOT resume.

**If it does not exist**: Create the work directory (`.forge/work/hotfix/{name}/`) and manifest using the template at `.claude/templates/manifests/hotfix.yaml`. Fill placeholders `{name}`, `{description}`, `{date}`.

## Step 1: Debug — Compressed Root Cause Analysis

REQUIRED SUB-SKILL: Use **support-debug** in compressed mode.
Focus on immediate fix. If root cause not identifiable quickly, recommend **rollback**.

## Step 2: Build — Minimal Fix with Test

REQUIRED SUB-SKILL: Use **build-tdd** (minimal scope).
Reproduce with a test, write the smallest fix, verify. Do not refactor.

## Step 3: Quality — Smoke Tests Only

REQUIRED SUB-SKILL: Use **quality-test-execution** (smoke tests ONLY).
Bar: existing tests pass + regression test + smoke tests. Full suite deferred to follow-up.

## Step 4: Quality — Quick Code Review

REQUIRED SUB-SKILL: Use **quality-code-review** (critical-pass only).
Catches injection, secrets, auth bypass. Full review deferred to follow-up.

## Step 5: Deliver — Deploy

REQUIRED SUB-SKILL: Use **deliver-deploy**.

## Step 6: Follow-Up (Critical)

### 6a: Record Gotcha
REQUIRED SUB-SKILL: Use **support-gotcha**.

Tag the gotcha with `severity: hotfix-workaround`. This tag is surfaced at session start by the forge session hook — it will remind you (or your teammates) about unresolved workarounds until a follow-up resolves them.

### 6b: Record Follow-Up
Document what needs to happen next. This is NOT optional — the hotfix cannot be marked complete without it.

```
Follow-up label: {short description, e.g., "payment-null-check-proper-fix"}
What was deferred: root cause deep dive, comprehensive test coverage, monitoring improvements, architectural review (if band-aid fix)
Resolved: false
```

Store in the gotcha file alongside the `hotfix-workaround` tag. When the follow-up is completed (via `/bugfix` or `/feature`):
- Update `resolved: true` in the gotcha file to clear the session start warning.
- Set `successor_path: work/{type}/{follow-up-name}` on the hotfix manifest.
- Leave `status: completed` on the hotfix manifest (not `escalated` — the hotfix deploy itself was complete).

## Explicit Gate Exemptions

| Standard Gate | Hotfix Scope |
|---|---|
| Full brainstorm | Skipped |
| Full architecture | Skipped |
| Full test plan | Smoke + regression only |
| Full code review | Critical pass only |
| Zero test failures (all types) | Existing + smoke pass |

Every skipped gate MUST be addressed in the follow-up ticket (Step 6b).