Day One Patch

---
name: day-one-patch
description: "为首日已知问题准备聚焦补丁，收集已知 Bug、排序优先级、准备修复并生成补丁说明。"
license: MIT
metadata:
  model: sonnet
  argument-hint: "[版本号]"
  user-invocable: true
  allowed-tools:
    - Read
    - Glob
    - Grep
    - Write
    - AskUserQuestion
  platforms:
    claude-code: {enabled: true}
    cursor: {enabled: true}
    codex: {enabled: true}
    windsurf: {enabled: true, trigger: /day-one-patch}
    trae: {enabled: true}
    hermes: {enabled: true, platforms: [macos, linux, windows]}
    workbuddy: {enabled: true}
---

# day-one-patch — 首日已知问题补丁准备

## 技能目的

为版本发布首日已知的遗留问题准备聚焦补丁，收集已知 Bug、按优先级排序、准备修复方案、生成补丁说明并验证，确保首日用户体验不受已知缺陷严重影响。

## 参数说明

- `[版本号]`：可选，指定已发布版本号。省略时从最新发布记录推断。

## 分阶段工作流

### 阶段 1：收集已知 Bug

- **输入**：版本号参数
- **处理**：
  1. 使用 Glob 查找 `docs/issues/`、`docs/bugs/` 已知问题清单
  2. 使用 Grep 搜索代码中标记为 `KNOWN ISSUE`、`DAY-ONE` 的条目
  3. 使用 Read 读取发布检查报告中标注的可接受遗留问题
  4. 使用 AskUserQuestion 与用户确认是否有额外已知问题
  5. 收集来自冒烟测试、压测、安全审计中暂缓修复的项
- **输出**：已知 Bug 清单

### 阶段 2：按优先级排序

- **输入**：已知 Bug 清单
- **处理**：
  1. 评估每个 Bug 对首日用户的影响面（受影响用户比例）
  2. 评估严重程度（崩溃、数据丢失、功能不可用、体验受损）
  3. 评估修复成本与风险（改动范围、回归风险）
  4. 使用 AskUserQuestion 与用户确认优先级排序偏好
  5. 按影响×严重÷成本排序
- **输出**：优先级排序的 Bug 清单

### 阶段 3：准备修复

- **输入**：排序后的 Bug 清单
- **处理**：
  1. 为每个高优先级 Bug 制定最小修复方案
  2. 限定修复范围，避免引入大改动
  3. 使用 Read 读取受影响代码，确认修复位置
  4. 使用 Grep 检查修复是否会触及公共接口
  5. 标注每个修复的回归测试需求
- **输出**：修复方案清单

### 阶段 4：生成补丁说明

- **输入**：修复方案清单
- **处理**：
  1. 使用 Write 生成补丁说明 `docs/release/day-one-patch-{版本}.md`
  2. 说明含：补丁版本号、修复的 Bug 列表、影响范围、升级步骤
  3. 对每个修复给出用户可感知的变化描述
  4. 标注暂未修复的已知问题及规避方案
- **输出**：补丁说明文档

### 阶段 5：验证

- **输入**：补丁说明文档
- **处理**：
  1. 使用 Glob 查找补丁对应的测试用例
  2. 使用 AskUserQuestion 与用户确认验证范围
  3. 列出验证清单：回归测试、冒烟测试、手动验证
  4. 标注补丁发布的窗口与回滚方案
  5. 使用 Write 更新补丁说明追加验证记录
- **输出**：验证完成的补丁说明

## 协作协议引用

- 遵循 `.claude/docs/coding-standards.md` 编码规范
- 补丁说明写入 `docs/release/` 目录
- 补丁发布需用户最终批准
- 修复范围严格最小化，避免引入新风险

## 推荐下一步

使用 `/smoke-check` 验证补丁后核心路径。使用 `/patch-notes` 生成面向用户的补丁说明。使用 `/release-checklist` 为补丁版本执行发布检查。