Back to Details

hotfix

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Explicit invocation only: This skill should only run when the user explicitly requests it with 
/hotfix
. Do not auto-invoke based on context matching.
仅允许显式调用：此技能仅在用户通过
/hotfix
明确请求时运行，请勿根据上下文匹配自动调用。

Phase 1: Assess Severity

阶段1：评估严重程度

Read the bug description or ID. Assess severity using these criteria:
  • S1 (Critical): Game unplayable, data loss, security vulnerability
  • S2 (Major): Significant feature broken, workaround exists
  • S3 or lower: Minor issue — normal bug fix workflow applies
Confirm with 
AskUserQuestion
:
  • Prompt: "I've assessed this as [assessed severity] — [brief rationale]. Confirm severity to proceed:"
  • Options: 
    • [A] S1 (Critical) — game unplayable, data loss, or security issue
    • [B] S2 (Major) — significant feature broken, workaround exists
    • [C] S3 or lower — redirect to normal bug fix workflow
If [C]: stop. Verdict: REDIRECTED — use the normal bug fix workflow for S3 and below.
阅读bug描述或ID，使用以下标准评估严重程度：
  • S1（严重）：游戏无法游玩、数据丢失、安全漏洞
  • S2（主要）：重要功能故障，但存在临时解决方案
  • S3及以下：次要问题——适用常规bug修复工作流
使用
AskUserQuestion
确认：
  • 提示语："我已将该问题评估为**[评估的严重等级]**——[简要理由]。请确认严重等级以继续："
  • 选项： 
    • [A] S1（严重）——游戏无法游玩、数据丢失或安全问题
    • [B] S2（主要）——重要功能故障，但存在临时解决方案
    • [C] S3及以下——转至常规bug修复工作流
若选择[C]：停止操作。结论：已转至——S3及以下问题使用常规bug修复工作流。

Phase 2: Create Hotfix Record

阶段2：创建热修复记录

Draft the hotfix record:
markdown
undefined
起草热修复记录：
markdown
undefined

Hotfix: [Short Description]

Hotfix: [简短描述]

Date: [Date] Severity: [S1/S2] Reporter: [Who found it] Status: IN PROGRESS
日期: [日期] 严重等级: [S1/S2] 报告人: [发现者] 状态: 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)
  • 修复方案经首席程序员（lead-programmer）审核
  • 回归测试通过（qa-tester）
  • 发布获批准（producer）

Rollback Plan

回滚计划

[How to revert if the fix causes new issues]

Ask: "May I write this to `production/hotfixes/hotfix-[date]-[short-name].md`?"

If yes, write the file, creating the directory if needed.

---
[若修复引发新问题，如何回退]

询问："是否可以将此记录写入`production/hotfixes/hotfix-[date]-[short-name].md`？"

若同意，写入文件，必要时创建对应目录。

---

Phase 3: Create Hotfix Branch

阶段3：创建热修复分支

Check whether this is a git repository:
Bash: git rev-parse --is-inside-work-tree 2>/dev/null
If this command fails or returns empty: note "Not a git repository — create the branch manually." and skip branch creation.
If the check passes, use 
AskUserQuestion
before creating the branch:
  • Prompt: "Ready to create hotfix branch 'hotfix/[short-name]' from [base-ref]?"
  • Options: 
    • [A] Yes — create branch
    • [B] Use a different base ref — I'll specify it
    • [C] Skip — I'll create the branch myself
Only run 
git checkout -b hotfix/[short-name] [base-ref]
if user selects [A]. If [B]: ask the user for the base ref, then run the command with that ref. If [C]: skip branch creation and proceed to Phase 4.
检查当前是否为git仓库：
Bash: git rev-parse --is-inside-work-tree 2>/dev/null
若该命令执行失败或返回空值：记录"非git仓库——请手动创建分支。"并跳过分支创建步骤。
若检查通过，创建分支前使用
AskUserQuestion
确认：
  • 提示语："准备从[base-ref]创建热修复分支'hotfix/[short-name]'，是否确认？"
  • 选项： 
    • [A] 是——创建分支
    • [B] 使用其他基准分支——我将指定分支
    • [C] 跳过——我将手动创建分支
仅当用户选择[A]时，执行
git checkout -b hotfix/[short-name] [base-ref]
。若选择[B]：询问用户指定基准分支，再执行对应命令。若选择[C]：跳过分支创建，进入阶段4。

Phase 4: Investigate and Implement

阶段4：调查与实施

Focus on the minimal change that resolves the issue. Do NOT refactor, clean up, or add features alongside the hotfix.
Validate the fix by running targeted tests for the affected system. Check for regressions in adjacent systems.
Update the hotfix record with root cause, fix details, and test results.
专注于解决问题的最小改动。请勿在热修复同时进行重构、代码清理或新增功能。
通过针对受影响系统运行定向测试验证修复效果，检查相邻系统是否出现回归问题。
更新热修复记录，填写根本原因、修复详情及测试结果。

Phase 5: Collect Approvals

阶段5：收集审批意见

Use the Task tool to request sign-off in parallel:
  • 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
All three must return APPROVE before proceeding. If any returns CONCERNS or REJECT, do not deploy — surface the issue and resolve it first.
使用Task工具并行请求签字确认：
  • subagent_type: lead-programmer
    ——审核修复方案的正确性及潜在副作用
  • subagent_type: qa-tester
    ——针对受影响系统运行定向回归测试
  • subagent_type: producer
    ——批准部署时间及沟通计划
必须获得三方全部批准后才能继续。若任何一方提出疑问或拒绝，请勿部署——先暴露问题并解决。

Phase 5b: QA Re-Entry Gate

阶段5b：QA二次验证关口

After approvals, determine the QA scope required before deploying the hotfix. Spawn 
qa-lead
via Task with:
  • The hotfix description and affected system
  • The regression test results from Phase 5
  • A list of all systems that touch the changed files (use Grep to find callers)
Ask qa-lead: Is a full smoke check sufficient, or does this fix require a targeted team-qa pass?
Apply the verdict:
  • Smoke check sufficient — run 
    /smoke-check
    against the hotfix build. If PASS, proceed to Phase 6.
  • Targeted QA pass required — run 
    /team-qa [affected-system]
    scoped to the changed system only. If QA returns APPROVED or APPROVED WITH CONDITIONS, proceed to Phase 6.
  • Full QA required — S1 fixes that touch core systems may require a full 
    /team-qa sprint
    . This delays deployment but prevents a bad patch.
Do not skip this gate. A hotfix that breaks something else is worse than the original bug.
获得审批后，确定部署热修复前所需的QA范围。通过Task调用
qa-lead
，并提供：
  • 热修复描述及受影响系统
  • 阶段5的回归测试结果
  • 所有涉及变更文件的关联系统列表（使用Grep查找调用方）
询问qa-lead：仅需完整冒烟测试即可，还是该修复需要针对性团队QA测试？
根据结论执行：
  • 仅需冒烟测试——针对热修复构建运行
    /smoke-check
    。若通过，进入阶段6。
  • 需针对性QA测试——运行
    /team-qa [affected-system]
    ，仅覆盖变更涉及的系统。若QA返回APPROVED或APPROVED WITH CONDITIONS，进入阶段6。
  • 需完整QA测试——涉及核心系统的S1修复可能需要完整的
    /team-qa sprint
    。这会延迟部署，但可避免不良补丁。
请勿跳过此关口。引发新问题的热修复比原bug更糟糕。

Phase 6: Update Bug Status and Deploy

阶段6：更新Bug状态并部署

Update the original bug file if one exists:
markdown
undefined
若存在原始bug文件，更新该文件：
markdown
undefined

Fix Record

修复记录

Fixed in: hotfix/[branch-name] — [commit hash or description] Fixed date: [date] Status: Fixed — Pending Verification

Set `**Status**: Fixed — Pending Verification` in the bug file header.

Output a deployment summary:
修复于: hotfix/[分支名称] — [提交哈希或描述] 修复日期: [日期] 状态: Fixed — Pending Verification

在bug文件头部设置`**状态**: Fixed — Pending Verification`。

输出部署摘要：

Hotfix Ready to Deploy: [short-name]

热修复已准备部署: [short-name]

Severity: [S1/S2] Root cause: [one line] Fix: [one line] QA gate: [Smoke check PASS / Team-QA APPROVED] Approvals: lead-programmer ✓ / qa-tester ✓ / producer ✓ Rollback plan: [from Phase 2 record]
Merge to: release branch AND development branch Next: /bug-report verify [BUG-ID] after deploy to confirm resolution
undefined
严重等级: [S1/S2] 根本原因: [一句话描述] 修复方案: [一句话描述] QA验证: [冒烟测试通过 / 团队QA已批准] 审批状态: lead-programmer ✓ / qa-tester ✓ / producer ✓ 回滚计划: [来自阶段2的记录]
合并至: 发布分支 及 开发分支 下一步: 部署后运行
/bug-report verify [BUG-ID]
确认问题已解决
undefined

Rules

规则

  • Hotfixes must be the MINIMUM change to fix the issue — no cleanup, no refactoring
  • 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
  • 热修复必须是解决问题的最小改动——禁止清理代码、重构或新增功能
  • 每个热修复在部署前必须记录回滚计划
  • 热修复分支必须同时合并至发布分支和开发分支
  • 所有热修复必须在48小时内进行事后复盘
  • 若修复复杂度超过4小时工作量，升级至
    technical-director
    处理

Phase 7: Post-Deploy Verification

阶段7：部署后验证

After deploying, run 
/bug-report verify [BUG-ID]
to confirm the fix resolved the issue in the deployed build.
If VERIFIED FIXED: run 
/bug-report close [BUG-ID]
to formally close it. If STILL PRESENT: the hotfix failed — immediately re-open, assess rollback, and escalate.
Schedule a post-incident review within 48 hours using 
/retrospective hotfix
.
Use 
AskUserQuestion
:
  • Prompt: "Hotfix complete. What's the next step?"
  • Options: 
    • [A] Run /smoke-check to verify the fix
    • [B] Run /patch-notes to document this hotfix
    • [C] Stop here
部署完成后，运行
/bug-report verify [BUG-ID]
确认修复已在部署版本中解决问题。
若验证通过：运行
/bug-report close [BUG-ID]
正式关闭该bug。 若问题仍存在：热修复失败——立即重新打开bug，评估回滚方案并升级处理。
使用
/retrospective hotfix
安排48小时内的事后复盘。
使用
AskUserQuestion
询问：
  • 提示语："热修复已完成。下一步操作？"
  • 选项： 
    • [A] 运行/smoke-check验证修复效果
    • [B] 运行/patch-notes记录该热修复
    • [C] 到此为止