# Day One Patch > Prepara un patch day-one para el lanzamiento de un juego: define alcance, prioriza, implementa y valida con un QA gate ligero, como un mini-sprint con plan de rollback. Fuente: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/day-one-patch Markdown: https://skillsagentes.com/skills/donchitos/claude-code-game-studios/day-one-patch.md Repositorio: https://github.com/Donchitos/Claude-Code-Game-Studios Autor: Donchitos Licencia: MIT Actualizado: hace 3 meses Coste de contexto: 70 tok instalada, 2.1k tok al activarse, 2.1k tok con todos los archivos del bundle Bundle: 1 archivo, 8 KB Permisos que pide: read, glob, grep, write, edit, bash, task, askuserquestion ## Instalación Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina. ```bash # Claude Code npx -y skills add Donchitos/Claude-Code-Game-Studios --skill day-one-patch --agent claude-code # Cursor npx -y skills add Donchitos/Claude-Code-Game-Studios --skill day-one-patch --agent cursor # Codex npx -y skills add Donchitos/Claude-Code-Game-Studios --skill day-one-patch --agent codex # Gemini CLI npx -y skills add Donchitos/Claude-Code-Game-Studios --skill day-one-patch --agent gemini # Windsurf npx -y skills add Donchitos/Claude-Code-Game-Studios --skill day-one-patch --agent windsurf # Cline npx -y skills add Donchitos/Claude-Code-Game-Studios --skill day-one-patch --agent cline ``` ## Qué hace - Escanea bugs abiertos, contexto de release y feedback de cert para proponer el alcance de un patch day-one - Clasifica bugs incluidos/diferidos según severidad, riesgo y esfuerzo estimado - Genera un plan de rollback obligatorio antes de escribir cualquier código - Coordina agentes (lead-programmer, qa-tester, qa-lead) para implementar y verificar las correcciones - Produce el registro final del patch en production/releases/day-one-patch-[version].md ## Cuándo usarla - Después de bloquear el gold master (cert aprobado o launch candidate etiquetado) - Cuando hay bugs conocidos demasiado riesgosos para el gold master - Cuando el feedback de certificación exige correcciones menores post-envío - Cuando un playtest pre-lanzamiento revela problemas críticos tras pasar el release gate ## Cuándo no - El proyecto no está en etapa Release o Polish (según production/stage.txt) ## Qué la activa - "Prepara el patch day-one para la versión 1.0" - "Necesito planificar el parche de lanzamiento antes del día uno" - "Revisa los bugs abiertos y arma el alcance del day-one patch" - "Genera el plan de rollback para el lanzamiento de mañana" ## Antes de instalar - Requiere que production/stage.txt indique Release o Polish y que existan archivos de gate-checks, bugs y sprints previos. - runs shell commands - writes to your files ## Archivos - SKILL.md — 8 KB ## SKILL.md Reproducido tal cual desde Donchitos/Claude-Code-Game-Studios bajo MIT. Esta sección es el documento original y está en inglés. # 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: - `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 `production/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." --- ## 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 Task. 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 bug in the approved scope, spawn a focused implementation loop: 1. Spawn `lead-programmer` via Task 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) 2. The lead-programmer implements and runs targeted tests. 3. Spawn `qa-tester` via Task to verify: does the bug reproduce after the fix? For config/data-only fixes: make the change directly (no programmer agent needed). Confirm the value changed and re-run any relevant smoke test. --- ## Phase 5: Patch QA Gate This is a lightweight QA pass — not a full `/team-qa`. The patch is already QA-approved from the release gate; we are only re-verifying the changed areas. Spawn `qa-lead` via Task with: - List of all changed files - List of bugs fixed (with verification status from Phase 4) - The smoke check scope for the affected systems Ask qa-lead to determine: **Is a targeted smoke check sufficient, or do any fixes touch systems that require a broader regression?** Run the required QA scope: - **Targeted smoke check** — run `/smoke-check [affected-systems]` - **Broader regression** — run targeted tests in `tests/unit/` and `tests/integration/` for affected systems QA verdict must be PASS or PASS WITH WARNINGS before proceeding. If FAIL: scope the failing fix out of the day-one patch and defer to 1.1. --- ## Phase 6: Generate Patch Record ```markdown # Day-One Patch: [Game Name] v[version] **Date prepared**: [date] **Target release**: [launch date or "day of launch"] **Base build**: [gold master tag or commit] **Patch build**: [patch tag or commit] --- ## Patch Notes (Internal) ### Bugs Fixed | BUG-ID | Severity | Description | Fix summary | |--------|----------|-------------|-------------| | BUG-NNN | S[1-4] | [description] | [one-line fix] | ### Deferred to 1.1 | BUG-ID | Severity | Description | Reason deferred | |--------|----------|-------------|-----------------| | BUG-NNN | S[1-4] | [description] | [reason] | --- ## QA Sign-Off **QA scope**: [Targeted smoke / Broader regression] **Verdict**: [PASS / PASS WITH WARNINGS] **QA lead**: qa-lead agent **Date**: [date] **Warnings (if any)**: [list or "None"] --- ## Rollback Plan See: `production/releases/rollback-plan-[version].md` **Trigger condition**: If [N] or more S1 bugs are reported within [X] hours of launch, execute rollback. **Rollback owner**: [user / producer] --- ## Approvals Required Before Deploy - [ ] lead-programmer: all fixes reviewed - [ ] qa-lead: QA gate PASS confirmed - [ ] producer: deployment timing approved - [ ] release-manager: platform submission confirmed --- ## Player-Facing Patch Notes [Draft for community-manager to review before publishing] [list player-facing changes in plain language] ``` Ask: "May I write this patch record to `production/releases/day-one-patch-[version].md`?" --- ## Phase 7: Next Steps After the patch record is written: 1. Run `/patch-notes` to generate the player-facing version of the patch notes 2. Run `/bug-report verify [BUG-ID]` for each fixed bug after the patch is live 3. Run `/bug-report close [BUG-ID]` for each verified fix 4. Schedule a post-launch review 48–72 hours after launch using `/retrospective launch` **If any S1 bugs remain open after the patch:** > "⚠️ S1 bugs remain open and were not patched. These are accepted risks. Document them in the rollback plan trigger conditions — if they occur at scale, rollback may be preferable to a follow-up patch." Use `AskUserQuestion`: - Prompt: "Day-one patch complete. What's next?" - Options: - `[A] Run /patch-notes — generate player-facing patch notes` - `[B] Run /bug-report to log any issues found post-deploy` - `[C] Stop here` --- ## Collaborative Protocol - **Scope discipline is everything** — resist scope creep; every addition increases risk - **Rollback plan first, always** — a patch without a rollback plan is irresponsible - **Deferred is not forgotten** — every deferred bug gets a 1.1 ticket automatically - **Player communication is part of the patch** — `/patch-notes` is a required output, not optional ## Dónde encaja - Categoría: [Testing y QA](https://skillsagentes.com/categorias/testing-qa.md) — Flujos de testing unitario, de integración y end-to-end. - Creador: [Donchitos](https://skillsagentes.com/creators/donchitos.md) — 73 skills en el directorio - [Todas las skills](https://skillsagentes.com/skills.md) - [Ranking de instalaciones](https://skillsagentes.com/ranking.md) ## Otras skills del mismo repositorio - [Team Qa](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/team-qa.md): Orquesta al equipo de QA (qa-lead y qa-tester) para producir un paquete completo de QA: plan de pruebas, smoke check, casos de prueba, ejecución manual y reporte de sign-off. - [Consistency Check](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/consistency-check.md): Compara todos los GDDs contra el registro de entidades para detectar inconsistencias entre documentos: mismo stat, ítem o fórmula con valores distintos, usando un enfoque grep-first. - [Create Architecture](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/create-architecture.md): Redacción guiada, sección por sección, del documento de arquitectura maestro del juego, consciente de la versión del motor y de sus posibles brechas de conocimiento. - [Hotfix](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/hotfix.md): Flujo de arreglo urgente que se salta el proceso normal de sprint pero deja rastro de auditoría completo: crea rama hotfix, registra aprobaciones y asegura el backport correcto. - [Adopt](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/adopt.md): Onboarding brownfield: audita el cumplimiento de formato de los artefactos existentes, clasifica los vacíos por impacto y genera un plan de migración numerado. ## Skills relacionadas - [Team Qa](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/team-qa.md): Orquesta al equipo de QA (qa-lead y qa-tester) para producir un paquete completo de QA: plan de pruebas, smoke check, casos de prueba, ejecución manual y reporte de sign-off. - [Consistency Check](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/consistency-check.md): Compara todos los GDDs contra el registro de entidades para detectar inconsistencias entre documentos: mismo stat, ítem o fórmula con valores distintos, usando un enfoque grep-first. - [Create Architecture](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/create-architecture.md): Redacción guiada, sección por sección, del documento de arquitectura maestro del juego, consciente de la versión del motor y de sus posibles brechas de conocimiento. - [Hotfix](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/hotfix.md): Flujo de arreglo urgente que se salta el proceso normal de sprint pero deja rastro de auditoría completo: crea rama hotfix, registra aprobaciones y asegura el backport correcto. - [Patch Notes](https://skillsagentes.com/skills/donchitos/claude-code-game-studios/patch-notes.md): Genera notas de parche para jugadores a partir del historial de git, datos de sprint y changelogs internos, traduciendo el lenguaje técnico a una comunicación clara y atractiva. --- Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)