Day-One Patch

Day-One Patch

What Is This

The Day-One Patch skill for the Happycapy Skills platform is a structured workflow tool designed for game development teams to prepare, scope, implement, and QA-gate a focused patch that is delivered immediately after a game's gold master build but before or just after public launch. This skill addresses the reality that almost every shipped game requires a day-one patch to resolve high-priority issues that surface late in production or during certification, but it does so with a disciplined, risk-managed approach. Unlike hotfixes or regular sprints, a day-one patch is intentionally scoped to minimize risk and maximize stability for launch day. The skill leverages a mini-sprint method: it identifies, prioritizes, implements, and QA-verifies only those fixes that are safe and critical, ensuring robust quality and a clear rollback plan.

Skill ID: day-one-patch
Category: design
Argument hint: [scope: known-bugs | cert-feedback | all]
Source: GitHub

Why Use It

Day-one patches are a cornerstone of modern game development, especially as games grow in complexity and as certification processes tighten. Attempting to patch at the last minute without a plan often results in regression bugs, missed critical fixes, or even certification failures. The Day-One Patch skill helps teams avoid launch chaos by enforcing a set of strict, safety-first guidelines for what can be changed after the gold master is locked. By treating this patch as a controlled mini-sprint rather than a frantic hotfix, teams can:

• Address must-fix issues found after gold master without destabilizing the build.
• Respond to final certification feedback that requires minor post-submission changes.
• Maintain a clear, auditable process with rollback options if a patch introduces problems.
• Avoid feature creep and risky refactors in the critical pre-launch window.

This skill is especially valuable for teams managing console or PC game launches, where certification timelines and launch deadlines leave no room for error.

How to Use It

1. Load Release

Context

Begin by confirming the current release context. The skill reads production/stage.txt to verify that the gold master build is locked, either through certification approval or by tagging the launch candidate. This prevents accidental use of the skill on unstable or pre-release builds.

cat production/stage.txt

2. Scope the

Patch

Invoke the skill with a scope argument:

• known-bugs - Targets only bugs identified post-gold master.
• cert-feedback - Focuses on fixes required by certification bodies.
• all - Includes both known bugs and cert feedback, but still filtered by strict safety rules.

The skill will scan issue trackers, certification logs, and playtest reports to compile a candidate list of bugs. It then filters these to include only P1/P2 (highest and high priority) issues that are safe and quick to fix.

3. Prioritize and

Implement

Only bugs that meet the following criteria can be included:

• The fix is limited to no more than 4 hours of development time.
• No new features or refactoring is allowed.
• All changes must be minimal, targeted, and low-risk.

A typical code review checklist for a day-one patch might look like:

- [ ] Is this a P1 or P2 bug?
- [ ] Does the fix avoid refactoring?
- [ ] Is the estimated dev time under 4 hours?
- [ ] Has the patch been reviewed for regression risk?

4. Lightweight QA

Gate

The patch is treated as a mini-sprint, with its own focused QA cycle. The skill outputs a detailed summary of changes and a test checklist. QA verifies only the changed areas and regression hotspots.

production/releases/day-one-patch-[version].md

Example output file:

## Day-One Patch v1.0.1

### Included Fixes
- [BUG-1421] Fixed crash on save when inventory is full
- [CERT-230] Adjusted privacy policy link for compliance

### QA Checklist
- [ ] Save/load with full inventory
- [ ] Privacy policy link opens correctly

5. Rollback

Planning

Before release, the skill ensures a rollback plan exists. For each fix, a revert commit is prepared, and release documentation includes instructions for rolling back the patch if necessary.

When to Use It

Use the Day-One Patch skill in the following scenarios:

• Immediately after your gold master build is locked and before public launch.
• When known, high-severity bugs surface that are too risky for inclusion in the gold master but must be fixed for launch.
• When certification responses require minimal but mandatory changes post-submission.
• After a pre-launch playtest surfaces "must-fix" issues following the release gate.

This skill should not be used for new features, major refactoring, or any fix requiring more than 4 hours of effort. Such work should be deferred to subsequent patches (e.g., Patch 1.1).

Important Notes

• The day-one patch is not a replacement for robust pre-launch QA or for mainline sprint work.
• All fixes must be minimal, safe, and justified by criticality.
• Always document each fix and verify with targeted QA.
• Maintain a clear rollback plan for every included change.

By following these guidelines and leveraging the Day-One Patch skill, teams can deliver a stable, high-quality launch experience without sacrificing safety or predictability.