/day-one-patch

name: day-one-patch
description: "Day-one launch patch — focused fix for known issues found after gold master. Mini-sprint with QA gate and rollback."
argument-hint: "[scope: known-bugs | cert-feedback | all]"
user-invocable: true
disable-model-invocation: true
allowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion
model: sonnet

Day-One Patch

Every shipped game has a day-one patch. Planning it before launch day prevents chaos. This skill scopes the patch to only what is safe and necessary, gates it through a lightweight QA pass, and ensures a rollback plan exists before anything ships. It is a mini-sprint — not a hotfix, not a full sprint.

**When to run:**

• After the gold master build is locked (cert approved or launch candidate tagged)
• When known bugs exist that are too risky to address in the gold master
• When cert feedback requires minor fixes post-submission
• When a pre-launch playtest surfaces must-fix issues after the release gate passed

**Day-one patch scope rules:**

• Only P1/P2 bugs that are SAFE to fix quickly
• No new features — this is fix-only
• No refactoring — minimum viable change
• Any fix that requires more than 4 hours of dev time belongs in patch 1.1, not day-one

**Output:** `production/releases/day-one-patch-[version].md`

---

Phase 1: Load Release Context

Read:

• `project.stage` in `project.yaml` (fallback `production/stage.txt`) — confirm project is in Release stage
• The most recent file in `production/gate-checks/` — read the release gate verdict
• `production/qa/bugs/*.md` — load all bugs with Status: Open or Fixed — Pending Verification
• `production/sprints/` most recent — understand what shipped
• `production/security/security-audit-*.md` most recent — check for any open security items

If the resolved stage (project.yaml → stage.txt) is not `Release` or `Polish`: > "Day-one patch prep is for Release-stage projects. Current stage: [stage]. This skill is not appropriate until you are approaching launch."

**Check the premise, do not assume it.** This whole skill rests on there being a gold master that already passed a release gate — that premise is what justifies its lightweight QA pass instead of a full one. So verify it rather than inferring it from the stage value:

• **No file in `production/gate-checks/`**, or none recording a release-gate

verdict: report `Release gate: NOT ASSESSED — no gate-check record found`. Do not proceed silently. Say plainly that the reduced QA scope below is justified by a gate nobody can find, and ask whether to run `/gate-check` first or proceed with a full QA pass instead.

• **The most recent record is FAIL, CONCERNS or NOT ASSESSED**: name it and stop.

A day-one patch on top of a build that never passed its gate is not a day-one patch; it is the release gate, arriving late and scoped to the wrong changes.

• `project.stage: Release` on its own does **not** establish this. The stage is a

claim about where the project is; the gate record is the evidence that it earned the position.

---

Phase 2: Scope the Patch

Step 2a — Classify open bugs for patch inclusion

For each open bug, evaluate:

| Criterion | Include in day-one? | |-----------|-------------------| | S1 or S2 severity | Yes — must include if safe to fix | | P1 priority | Yes | | Fix estimated < 4 hours | Yes | | Fix requires architecture change | No — defer to 1.1 | | Fix introduces new code paths | No — too risky | | Fix is data/config only (no code change) | Yes — very low risk | | Cert feedback requirement | Yes — required for platform approval | | S3/S4 severity | Only if trivial config fix; otherwise defer |

Step 2b — Present patch scope to user

Use `AskUserQuestion`:

• Prompt: "Based on open bugs and cert feedback, here is the proposed day-one patch scope. Does this look right?"
• Show: table of included bugs (ID, severity, description, estimated effort)
• Show: table of deferred bugs (ID, severity, reason deferred)
• Options: `[A] Approve this scope` / `[B] Adjust — I want to add or remove items` / `[C] No day-one patch needed`

If [C]: output "No day-one patch required. Proceed to `/launch-checklist`." Stop.

Step 2c — Check total scope

Sum estimated effort. If total exceeds 1 day of work: > "⚠️ Patch scope is [N hours] — this exceeds a safe day-one window. Consider deferring lower-priority items to patch 1.1. A bloated day-one patch introduces more risk than it removes."

Use `AskUserQuestion` to confirm proceeding or reduce scope.

---

Phase 3: Rollback Plan

Before any code is written, define the rollback procedure. This is non-negotiable.

Spawn `release-manager` via `Agent`. Ask them to produce a rollback plan covering:

• How to revert to the gold master build on each target platform
• Platform-specific rollback constraints (some platforms cannot roll back cert builds)
• Who is responsible for triggering the rollback
• What player communication is required if a rollback occurs

Present the rollback plan. Ask: "May I write this rollback plan to `production/releases/rollback-plan-[version].md`?"

Do not proceed to Phase 4 until the rollback plan is written.

---

Phase 4: Implement Fixes

For each code fix in the approved scope, spawn a focused implementation loop:

1. Spawn `lead-programmer` via `Agent` with:

• The bug report (exact reproduction steps and root cause if known)
• The constraint: minimum viable fix only, no cleanup
• The affected files (from bug report Technical Context section)

It returns, for each bug, the minimal fix and the files it would change — writing nothing.

2. Ask once, for the whole set: "May I apply these fixes? [BUG-ID → files, one line each]". No code changes before this approval.

3. On yes, hand each approved fix back to `lead-programmer` (a new `Agent` call carrying its plan) to implement it and run targeted tests with `commands.test` from `project.yaml`, narrowed to the affected suite where the runner allows — never