New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Day-One Patch Planner

by Donchitos in Donchitos/Claude-Code-Game-Studios

Scopes and gates a game's day-one patch after the gold master: fix-only changes, a lightweight QA pass and a rollback plan written before anything ships.

MITAuto-check: notesGame Development

Install Day-One Patch Planner

skills CLI
$ npx skills add Donchitos/Claude-Code-Game-Studios --skill day-one-patch -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Donchitos/Claude-Code-Game-Studios day-one-patch --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Donchitos/Claude-Code-Game-Studios.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/day-one-patch .claude/skills/day-one-patch && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
day-one-patch
GitHub stars
26k
Token cost
~2.8k tokens
SKILL.md length
1,402 words
Files
1
Skills in repo
73
Repo updated
First seen
Licence
MIT

At a glance

Scopes and gates a game's day-one patch after the gold master: fix-only changes, a lightweight QA pass and a rollback plan written before anything ships.

  • Works in 7 steps: Load Release Context → Scope the Patch → Rollback Plan → …
  • Planning a launch-day fix patch after the gold master has been locked
  • SKILL.md covers Phase 1: Load Release Context, Phase 2: Scope the Patch, Phase 3: Rollback Plan and Phase 4: Implement Fixes, plus 4 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

This skill treats the day-one patch as a mini-sprint, neither a hotfix nor a full sprint. It is meant for the period after the gold master build is locked, when known bugs were too risky to fix in it, cert feedback asks for small fixes, or a late playtest found must-fix issues. Scope is strict: only P1 and P2 bugs that are safe to fix quickly, no new features, no refactoring, and anything needing more than 4 hours of developer time moves to patch 1.1.

It starts by loading release context: the project stage from project.yaml (falling back to production/stage.txt), the latest gate-check verdict, open bugs in production/qa/bugs, the latest sprint and the latest security audit. If the stage is not Release or Polish it stops. If no release-gate record exists, or the latest one is a fail, concerns or not assessed, it says so and asks whether to run /gate-check first or do a full QA pass instead.

The result is a document under production/releases named for the patch version. The agent can read, search, write and edit files, run shell commands, launch subagents and ask you questions.

When your agent uses it

  • Planning a launch-day fix patch after the gold master has been locked
  • Deciding which known bugs are safe to fix before release and which wait for patch 1.1
  • Handling minor fixes requested in platform cert feedback after submission
  • Preparing a rollback plan and lightweight QA pass for a pre-launch patch

Example prompts

  • “Plan a day-one patch for our game; the gold master was locked yesterday and three P2 bugs remain open.”
  • “Which of the open bugs in production/qa/bugs are safe to include in the day-one patch?”
  • “Cert feedback asked for two small fixes. Scope them as a day-one patch with a rollback plan.”
  • “Check whether our release gate passed before we prepare the day-one patch.”

Requirements

  • A project laid out with production/ folders and a stage field in project.yaml
  • Pre-approved tools (allowed-tools): Read, Glob, Grep, Write, Edit, Bash, Agent, AskUserQuestion

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Load Release Context
  2. Scope the Patch
  3. Rollback Plan
  4. Implement Fixes
  5. Patch QA Gate
  6. Generate Patch Record
  7. Next Steps

What it can do on your machine

Read from SKILL.md and the folder at commit b21fa0f. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Glob
    • Grep
    • Write
    • Edit
    • Bash
    • Agent
    • AskUserQuestion

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Day-One Patch Planner loads about 2.8k tokens when it runs. Until then it costs about 32 tokens; SKILL.md has 1,402 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~32
When it runs · the whole SKILL.md, loaded when a task matches
~2.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Agent, AskUserQuestion

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Donchitos/Claude-Code-Game-Studios at commit b21fa0f, republished under its MIT licence (© Donchitos). 1,402 words, ~2,810 tokens.

Download SKILL.mdSave it as .claude/skills/day-one-patch/SKILL.md (or your agent's skills folder).
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.
allowed-tools
Read, Glob, Grep, Write, Edit, Bash, Agent, AskUserQuestion
argument-hint
[scope: known-bugs | cert-feedback | all]
user-invocable
true
disable-model-invocation
true
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:

CriterionInclude in day-one?
S1 or S2 severityYes — must include if safe to fix
P1 priorityYes
Fix estimated < 4 hoursYes
Fix requires architecture changeNo — defer to 1.1
Fix introduces new code pathsNo — too risky
Fix is data/config only (no code change)Yes — very low risk
Cert feedback requirementYes — required for platform approval
S3/S4 severityOnly 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 a runner line written from memory. If commands.test is unset, say so and record Tests: NOT RUN — commands.test unset for that bug.

  4. Spawn qa-tester via Agent to verify: does the bug reproduce after the fix?

For config/data-only fixes: make the change directly (no programmer agent needed). First ask, naming the file and the change: "May I edit [config file] — [key]: [old value] → [new value]?" Confirm the value changed and re-run any relevant smoke test.

Show full SKILL.md (486 more words)Show less

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 Agent 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 (it takes no system argument)
  • Broader regression — run the affected systems' tests in the engine's test root (tests/unit/ and tests/integration/ Godot, Assets/Tests/ Unity, Source/<Module>/Private/Tests/ Unreal — .claude/docs/directory-structure.md) with commands.test from project.yaml, narrowed to the affected suites where the runner allows — never a runner line written from memory. If commands.test is unset, the broader regression is NOT ASSESSED; say so.

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.

If the QA verdict is NOT ASSESSED, that is not a pass. /smoke-check returns it when the suite never ran — no build, no runner, or a result nobody confirmed. Do not proceed on it and do not re-read it as PASS WITH WARNINGS: the warnings value means somebody looked and saw something minor, and this means nobody looked. Either obtain the result (the verdict names what would make it runnable) or defer the fix to 1.1. A day-one patch ships to every player who buys the game on day one, which is the worst possible audience for an unverified change.

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-NNNN | S[1-4] | [description] | [one-line fix] |

### Deferred to 1.1
| BUG-ID | Severity | Description | Reason deferred |
|--------|----------|-------------|-----------------|
| BUG-NNNN | S[1-4] | [description] | [reason] |

---

## QA Sign-Off

**QA scope**: [Targeted smoke / Broader regression]
**Verdict**: [PASS / PASS WITH WARNINGS / NOT ASSESSED]
**QA lead**: qa-lead agent
**Date**: [date]
**Warnings (if any)**: [list or "None"]
**Not assessed (if any)**: [what could not be checked, and why — 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 [milestone-name] for the launch milestone in production/milestones/

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 is listed in the record's "Deferred to 1.1" table; run /bug-triage afterwards to schedule them into the 1.1 sprint
  • Player communication is part of the patch — /patch-notes is a required output, not optional

© Donchitos, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/day-one-patch of Donchitos/Claude-Code-Game-Studios.

Open the folder on GitHubat commit b21fa0f

Compare with similar skills

Day-One Patch Planner next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Day-One Patch Planner compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Day-One Patch Planner this skillDonchitos/Claude-Code-Game-Studios26k—~2.8kAutomated safety check: NotesMIT
Verification Gatesrohitg00/skillkit1.5k—~1.7kAutomated safety check: PassApache-2.0
Money Qualityiamzifei/show-me-the-money1k—~5.7kAutomated safety check: PassCustom licence
Steam Publishgamedev-skills/awesome-gamedev-agent-skills1.3k—~2.3kAutomated safety check: PassApache-2.0
Caveman Experiment ManagerJuliusBrussee/caveman110k1 repos~975Automated safety check: PassApache-2.0
Skill Release Gaterohitg00/ai-engineering-from-scratch65k—~1kAutomated safety check: PassMIT

Similar skills

  • Verification Gates

    rohitg00/skillkit

    Creates explicit validation checkpoints (verification gates) between project phases to catch errors early and ensure quality before proceeding.

    1.5k GitHub stars~1.7k tokensUpdated 4 mo ago
    Product & Project ManagementAuto-check passed

  • Money Quality

    iamzifei/show-me-the-money

    Code and product quality gates for shipping with confidence.

    1k GitHub stars~5.7k tokensUpdated 1 mo ago
    Testing & QAAuto-check passed

  • Steam Publish

    gamedev-skills/awesome-gamedev-agent-skills

    Publish or update a game on Steam with Steamworks and SteamPipe: configure depots and packages, upload builds with steamcmd, set a build live on a branch, and run the release checklists.

    1.3k GitHub stars~2.3k tokensUpdated 10 days ago
    Product & Project ManagementAuto-check passed

  • Caveman Experiment Manager

    JuliusBrussee/caveman

    Reads the state and results of Caveman Cloud experiments and reports one recommendation or a block, without changing an experiment's lifecycle itself.

    110k GitHub starsUsed in 1 repo~975 tokens
    AI & LLM EngineeringAuto-check passed

  • Skill Release Gate

    rohitg00/ai-engineering-from-scratch

    Evaluates an Agent Skill bundle before release for structure, trigger quality, artifact improvement, script correctness, safety, installed-tree integrity and host portability.

    65k GitHub stars~1k tokensUpdated today
    Agent WorkflowsAuto-check passed

  • Skill Authoring and Refactoring

    2025Emma/vibe-coding-cn

    Builds new skills from scattered docs, specs or code, and refactors existing skills for clear triggers, reliable activation and a quality checklist.

    23k GitHub starsUsed in 2 repos~2k tokens
    Agent WorkflowsAuto-check passed

More from Donchitos/Claude-Code-Game-Studios

All 73 skills in this repo

  • Game Asset Audit

    Donchitos/Claude-Code-Game-Studios

    Audits game assets against naming conventions, file size budgets and format standards, and finds orphaned assets and missing references.

    26k GitHub stars~2k tokensUpdated 8 days ago
    Auto-check passed

  • Game Asset Spec Writer

    Donchitos/Claude-Code-Game-Studios

    Writes per-asset visual specs and AI image-generation prompts for a game's characters, enemies and screens, driven by the GDD, art bible and an entity inventory.

    26k GitHub stars~5k tokensUpdated 8 days ago
    Auto-check passed

  • Game Balance Check

    Donchitos/Claude-Code-Game-Studios

    Checks game data and formulas for balance outliers, broken progression, degenerate strategies and economy problems, and answers 'could not run' when the data is missing.

    26k GitHub stars~2.2k tokensUpdated 8 days ago
    Auto-check passed

  • Structured Bug Reports

    Donchitos/Claude-Code-Game-Studios

    Turns a description into a structured bug report, or scans code for likely bugs, then verifies and closes reports through four modes.

    26k GitHub stars~2.5k tokensUpdated 8 days ago
    Auto-check: notes

  • Bug Triage

    Donchitos/Claude-Code-Game-Studios

    Reviews the open bug backlog, separates severity from priority, assigns fixes to sprints and reports systemic trends, writing a dated triage file.

    26k GitHub stars~2.3k tokensUpdated 8 days ago
    Auto-check passed

  • Changelog Generator for Games

    Donchitos/Claude-Code-Game-Studios

    Generates an internal or player-facing changelog from git commits and sprint data, filtering out framework maintenance commits so that only work on the game itself reaches release copy.

    26k GitHub stars~2.5k tokensUpdated 8 days ago
    Auto-check: notes

Categories

Questions about Day-One Patch Planner

What does Day-One Patch Planner do?

Scopes and gates a game's day-one patch after the gold master: fix-only changes, a lightweight QA pass and a rollback plan written before anything ships. This skill treats the day-one patch as a mini-sprint, neither a hotfix nor a full sprint. It is meant for the period after the gold master build is locked, when known bugs were too risky to fix in it, cert feedback asks for small fixes, or a late playtest found must-fix issues.

When should I use Day-One Patch Planner?

Day-One Patch Planner fits situations like: planning a launch-day fix patch after the gold master has been locked; deciding which known bugs are safe to fix before release and which wait for patch 1.1; handling minor fixes requested in platform cert feedback after submission; preparing a rollback plan and lightweight QA pass for a pre-launch patch.

How do I install Day-One Patch Planner in Claude Code?

Run `npx skills add Donchitos/Claude-Code-Game-Studios --skill day-one-patch -a claude-code`. Or copy the skill folder (.claude/skills/day-one-patch in Donchitos/Claude-Code-Game-Studios) into .claude/skills/day-one-patch in your project. Claude Code loads it when a task matches its description.

How do I install Day-One Patch Planner in Codex?

Run `npx skills add Donchitos/Claude-Code-Game-Studios --skill day-one-patch -a codex`. Or copy the skill folder (.claude/skills/day-one-patch in Donchitos/Claude-Code-Game-Studios) into .agents/skills/day-one-patch in your project. Codex loads it when a task matches its description.

Can I use Day-One Patch Planner in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Donchitos/Claude-Code-Game-Studios --skill day-one-patch -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/day-one-patch, .gemini/skills/day-one-patch, .github/skills/day-one-patch and .opencode/skills/day-one-patch in your project.

What does Day-One Patch Planner need to run?

SKILL.md names no scripts, command-line tools or credentials: Day-One Patch Planner is instructions for the agent only. Our summary lists: A project laid out with production/ folders and a stage field in project.yaml. Its frontmatter pre-approves these tools: Read, Glob, Grep, Write, Edit, Bash, Agent, AskUserQuestion.

Does Day-One Patch Planner access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Day-One Patch Planner safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Day-One Patch Planner use?

Day-One Patch Planner is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Day-One Patch Planner use?

About 2.8k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Day-One Patch Planner?

Skills that share tags, products or a category with Day-One Patch Planner: Verification Gates (rohitg00/skillkit, 1.5k stars), Money Quality (iamzifei/show-me-the-money, 1k stars), Steam Publish (gamedev-skills/awesome-gamedev-agent-skills, 1.3k stars) and Caveman Experiment Manager (JuliusBrussee/caveman, 110k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Day-One Patch Planner?

Donchitos (a GitHub user) maintains it in Donchitos/Claude-Code-Game-Studios, which has 25,834 GitHub stars. The repository holds 73 skills in this directory. The repository was last updated on September 29, 2026.

Source: Donchitos/Claude-Code-Game-Studios on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.