How to use the Day-One Patch Planner agent skill

What is an agent skill, and what does this one do?

An agent skill is a folder containing a SKILL.md file that gives an AI agent a specific, repeatable procedure to follow. This skill, day-one-patch, is one of those procedures. When it runs, the agent helps a game team prepare a fix-only patch for known issues found after the gold master build.

The skill is a mini-sprint, not a hotfix and not a full sprint. It limits the patch to fixes that are safe and necessary, and it stops if the project is not far enough along.

• Confirms the project is in the Release or Polish stage and that a release gate was passed
• Lists known bugs and proposes which ones are safe to include, and which to defer to a later patch
• Requires a written rollback plan before any code changes
• Gets approval before code changes, then uses specialist sub-agents to implement fixes
• Finishes with a targeted QA pass and a written patch record

Install the day-one-patch skill

Download the ZIP for the skill from the directory page and unzip it. The skill ships as a single file, SKILL.md. Put the skill folder in one of two places, depending on how you want to use it.

You can also upload the skill through the Claude apps: open Settings, go to Capabilities, then Skills, and upload it there.

• Personal install: unzip into ~/.claude/skills/ so it is available across your projects
• Project install: unzip into the .claude/skills/ folder of a specific project so it is available only there
• Claude apps: Settings → Capabilities → Skills, then upload the skill

Check that your project meets the requirements

The skill expects Claude Code running inside a Claude Code Game Studios project structure. It reads specific files and folders, and it calls specialist sub-agents by name. If these are missing, the skill will stop or ask for a full QA pass instead of a reduced one.

The optional commands.test entry in project.yaml tells the skill how to run tests. If it is not set, the skill records tests as not run rather than guessing a command.

• project.yaml, with a project.stage value (the skill falls back to production/stage.txt)
• production/gate-checks/ containing a release gate record with a verdict
• production/qa/bugs/ containing bug reports with Status values
• production/sprints/ and production/security/ folders
• Sub-agents: release-manager, lead-programmer, qa-tester and qa-lead
• Optional: a commands.test entry in project.yaml

Trigger the skill with a natural request

The skill accepts an optional scope argument: known-bugs, cert-feedback or all. You can invoke it with that argument, or describe what you want in plain language once the skill is installed.

Because the skill is set to be invoked by the user rather than automatically, it runs when you ask for it. Ask in terms of the day-one patch, the gold master or launch-day fixes.

• "Prepare the day-one patch scope for our gold master build."
• "Scope a launch-day patch using only the known bugs."
• "Plan a day-one patch from the cert feedback we received."
• "Run the day-one patch workflow for all open items."

Work through the patch scope and rollback plan

The skill first loads the release context: the stage, the latest gate-check record, open bugs, the most recent sprint and the latest security audit. If the most recent gate record is FAIL, CONCERNS or NOT ASSESSED, the skill stops, because a patch on an unvalidated build is the release gate arriving late.

Next it applies scope rules. Only P1 or P2 bugs that are safe to fix quickly are included, and any fix needing more than 4 hours of development time goes to patch 1.1. You then approve or adjust the scope. If the total exceeds one day of work, the skill warns you and asks whether to reduce it.

The rollback plan comes before any code is written. The release-manager sub-agent drafts it, and the skill asks permission before writing it to production/releases/rollback-plan-[version].md.

• Included: S1/S2 bugs safe to fix, P1 bugs, fixes under 4 hours, data or config-only fixes, and cert-required fixes
• Deferred: architecture changes, fixes that add new code paths, and S3/S4 bugs unless the fix is trivial config

Implement fixes and run the QA gate

Code changes are approved as a set. The lead-programmer sub-agent first proposes a minimal fix and the files it would change, without writing anything. You then approve the list. Only after approval does the programmer implement each fix and run targeted tests. The qa-tester sub-agent checks whether each bug still reproduces.

Config or data-only fixes are edited directly after you approve the specific file and value change. The final gate is a lightweight QA pass run by qa-lead. It decides whether a targeted smoke check is enough or whether a broader regression is needed.

• Smoke check: run /smoke-check, which takes no system argument
• Broader regression: run the affected suites with commands.test, narrowed where the runner allows
• A verdict of PASS or PASS WITH WARNINGS is required before proceeding
• A FAIL verdict means the failing fix is removed from the patch and deferred to 1.1
• NOT ASSESSED is treated as not passed

Safety notes: scripts and network

The skill does not run scripts and does not use the network. Its allowed tools are reading and searching files, writing and editing files, spawning sub-agents and asking you questions. Any test or smoke-check runs happen through the commands your project already defines.

Because the skill can write files and edit code, review each approval prompt before you accept it. Pay particular attention to the list of files to be changed and to any config value change.