hotfix

---
name: hotfix
description: "绕过正常 Sprint 流程的紧急修复工作流，附带完整的审计追踪。创建热修复分支、跟踪审批，并确保修复正确回移植。"
argument-hint: "[缺陷ID或描述]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Bash
---
当此技能被调用时：

> **仅限显式调用**：此技能仅应在用户通过 `/hotfix` 显式请求时运行。不要基于上下文匹配自动调用。

1. **评估紧急程度** — 读取缺陷描述或 ID。确定严重性：
   - **S1（严重）**：游戏无法游玩、数据丢失、安全漏洞 — 立即热修复
   - **S2（重大）**：重要功能损坏、存在变通方案 — 24 小时内热修复
   - 如果严重性为 S3 或更低，建议使用正常的缺陷修复工作流

2. **创建热修复记录**，保存至 `production/hotfixes/hotfix-[日期]-[简称].md`：

   ```markdown
   ## 热修复：[简要描述]
   日期：[日期]
   严重性：[S1/S2]
   报告人：[发现者]
   状态：进行中

   ### 问题描述
   [清晰描述损坏内容及其对玩家的影响]

   ### 根因分析
   [调查期间填写]

   ### 修复方案
   [实施期间填写]

   ### 测试情况
   [测试了什么以及如何测试]

   ### 审批
   - [ ] 修复已由 lead-programmer 审查
   - [ ] 回归测试已通过（qa-tester）
   - [ ] 发布已批准（producer）

   ### 回滚方案
   [如果修复导致新问题，如何回退]

3. 创建热修复分支（如果 git 已初始化）：

   git checkout -b hotfix/[简称] [发布标签或main]
   

4. 调查并实施修复 — 聚焦于解决问题的最小变更。不要在热修复的同时进行重构、清理或添加功能。

5. 验证修复 — 对受影响的系统运行针对性测试。检查相邻系统是否存在回归。

6. 更新热修复记录，填入根因分析、修复详情和测试结果。

6b. 收集审批 — 使用 Task 工具请求签字确认：

• subagent_type: lead-programmer — 审查修复的正确性和副作用
• subagent_type: qa-tester — 对受影响系统运行针对性回归测试
• subagent_type: producer — 批准部署时机和沟通计划

7. 输出摘要，包含：严重性、根因、已实施的修复、测试状态，以及部署前仍需哪些审批。

规则

• 热修复必须是解决问题的最小变更 — 不清理、不重构、不做"既然来了顺便改改"的变更
• 每个热修复在部署前必须记录回滚方案
• 热修复分支必须同时合并到发布分支和开发分支
• 所有热修复必须在 48 小时内完成事后复盘
• 如果修复复杂到需要超过 4 小时，上报至 technical-director 进行范围决策