agentleFS
CoralGameCoralGame/Claude-Code-Game-Studios/.claude/skills/hotfix/SKILL.md

hotfix

Skill19 starsChanged 7 months agoMITView on GitHub

Emergency fix workflow that bypasses normal sprint processes with a full audit trail. Creates hotfix branch, tracks approvals, and ensures the fix is backported correctly.

We split this skill into the rules it gives an agent

5 rules. 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 25 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When this skill is invoked:

    line 8
  2. Distinctive:

    If severity is S3 or lower, recommend using the normal bug fix workflow instead

    line 15
  3. Distinctive:

    Every hotfix must have a rollback plan documented before deployment

    line 67
  4. Distinctive:

    All hotfixes require a post-incident review within 48 hours

    line 69
  5. Distinctive:

    If the fix is complex enough to need more than 4 hours, escalate to technical-director for a scope decision

    line 70

“Common” is measured: kept by at least 6 in 10 of the 25 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

When this skill is invoked:

Explicit invocation only: This skill should only run when the user explicitly requests it with /hotfix. Do not auto-invoke based on context matching.

  1. Assess the emergency — Read the bug description or ID. Determine severity:
    • S1 (Critical): Game unplayable, data loss, security vulnerability — hotfix immediately
    • S2 (Major): Significant feature broken, workaround exists — hotfix within 24 hours
    • If severity is S3 or lower, recommend using the normal bug fix workflow instead
  2. Create the hotfix record at production/hotfixes/hotfix-[date]-[short-name].md:

    ## Hotfix: [Short Description]
    Date: [Date]
    Severity: [S1/S2]
    Reporter: [Who found it]
    Status: IN PROGRESS
    
    ### Problem
    [Clear description of what is broken and the player impact]
    
    ### Root Cause
    [To be filled during investigation]
    
    ### Fix
    [To be filled during implementation]
    
    ### Testing
    [What was tested and how]
    
    ### Approvals
    - [ ] Fix reviewed by lead-programmer
    - [ ] Regression test passed (qa-tester)
    - [ ] Release approved (producer)
    
    ### Rollback Plan
    [How to revert if the fix causes new issues]
  3. Create the hotfix branch (if git is initialized):
    git checkout -b hotfix/[short-name] [release-tag-or-main]
  4. Investigate and implement the fix — Focus on the minimal change that resolves the issue. Do NOT refactor, clean up, or add features alongside the hotfix.
  5. Validate the fix — Run targeted tests for the affected system. Check for regressions in adjacent systems.
  6. Update the hotfix record with root cause, fix details, and test results.

6b. Collect approvals — Use the Task tool to request sign-off:

  • subagent_type: lead-programmer — Review the fix for correctness and side effects
  • subagent_type: qa-tester — Run targeted regression tests on the affected system
  • subagent_type: producer — Approve deployment timing and communication plan
  1. Output a summary with: severity, root cause, fix applied, testing status, and what approvals are still needed before deployment.

Rules

  • Hotfixes must be the MINIMUM change to fix the issue — no cleanup, no refactoring, no "while we're here" changes
  • Every hotfix must have a rollback plan documented before deployment
  • Hotfix branches merge to BOTH the release branch AND the development branch
  • All hotfixes require a post-incident review within 48 hours
  • If the fix is complex enough to need more than 4 hours, escalate to technical-director for a scope decision

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.