Name: day-one-patch
Author: zls3434

Prompt file imported from zls3434/quick-input (.windsurf/workflows/day-one-patch.md). Copyright stays with the author.

/day-one-patch — 为首日已知问题准备聚焦补丁，收集已知 Bug、排序优先级、准备修复并生成补丁说明。

触发方式

在 Cascade 对话框中输入 /day-one-patch 触发此工作流。

工作流内容

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 为补丁版本执行发布检查。

Install day-one-patch and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# /day-one-patch — 为首日已知问题准备聚焦补丁，收集已知 Bug、排序优先级、准备修复并生成补丁说明。 ## 触发方式在 Cascade 对话框中输入 /day-one-patch 触发此工作流。 ## 工作流内容 # 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` 为补丁版本执行发布检查。

{ "prompt": "# /day-one-patch — 为首日已知问题准备聚焦补丁，收集已知 Bug、排序优先级、准备修复并生成补丁说明。\n\n## 触发方式\n在 Cascade 对话框中输入 /day-one-patch 触发此工作流。\n\n## 工作流内容\n# day-one-patch — 首日已知问题补丁准备\n\n## 技能目的\n\n为版本发布首日已知的遗留问题准备聚焦补丁，收集已知 Bug、按优先级排序、准备修复方案、生成补丁说明并验证，确保首日用户体验不受已知缺陷严重影响。\n\n## 参数说明\n\n- `[版本号]`：可选，指定已发布版本号。省略时从最新发布记录推断。\n\n## 分阶段工作流\n\n### 阶段 1：收集已知 Bug\n\n- **输入**：版本号参数\n- **处理**：\n 1. 使用 Glob 查找 `docs/issues/`、`docs/bugs/` 已知问题清单\n 2. 使用 Grep 搜索代码中标记为 `KNOWN ISSUE`、`DAY-ONE` 的条目\n 3. 使用 Read 读取发布检查报告中标注的可接受遗留问题\n 4. 使用 AskUserQuestion 与用户确认是否有额外已知问题\n 5. 收集来自冒烟测试、压测、安全审计中暂缓修复的项\n- **输出**：已知 Bug 清单\n\n### 阶段 2：按优先级排序\n\n- **输入**：已知 Bug 清单\n- **处理**：\n 1. 评估每个 Bug 对首日用户的影响面（受影响用户比例）\n 2. 评估严重程度（崩溃、数据丢失、功能不可用、体验受损）\n 3. 评估修复成本与风险（改动范围、回归风险）\n 4. 使用 AskUserQuestion 与用户确认优先级排序偏好\n 5. 按影响×严重÷成本排序\n- **输出**：优先级排序的 Bug 清单\n\n### 阶段 3：准备修复\n\n- **输入**：排序后的 Bug 清单\n- **处理**：\n 1. 为每个高优先级 Bug 制定最小修复方案\n 2. 限定修复范围，避免引入大改动\n 3. 使用 Read 读取受影响代码，确认修复位置\n 4. 使用 Grep 检查修复是否会触及公共接口\n 5. 标注每个修复的回归测试需求\n- **输出**：修复方案清单\n\n### 阶段 4：生成补丁说明\n\n- **输入**：修复方案清单\n- **处理**：\n 1. 使用 Write 生成补丁说明 `docs/release/day-one-patch-{版本}.md`\n 2. 说明含：补丁版本号、修复的 Bug 列表、影响范围、升级步骤\n 3. 对每个修复给出用户可感知的变化描述\n 4. 标注暂未修复的已知问题及规避方案\n- **输出**：补丁说明文档\n\n### 阶段 5：验证\n\n- **输入**：补丁说明文档\n- **处理**：\n 1. 使用 Glob 查找补丁对应的测试用例\n 2. 使用 AskUserQuestion 与用户确认验证范围\n 3. 列出验证清单：回归测试、冒烟测试、手动验证\n 4. 标注补丁发布的窗口与回滚方案\n 5. 使用 Write 更新补丁说明追加验证记录\n- **输出**：验证完成的补丁说明\n\n## 协作协议引用\n\n- 遵循 `.claude/docs/coding-standards.md` 编码规范\n- 补丁说明写入 `docs/release/` 目录\n- 补丁发布需用户最终批准\n- 修复范围严格最小化，避免引入新风险\n\n## 推荐下一步\n\n使用 `/smoke-check` 验证补丁后核心路径。使用 `/patch-notes` 生成面向用户的补丁说明。使用 `/release-checklist` 为补丁版本执行发布检查。", "variables": [], "notes": "为版本发布首日已知的遗留问题准备聚焦补丁，收集已知 Bug、按优先级排序、准备修复方案、生成补丁说明并验证，确保首日用户体验不受已知缺陷严重影响。", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/zls3434/quick-input", "path": ".windsurf/workflows/day-one-patch.md", "ref": "4f48bbd849b63514812e8ef32a94a4fe19b9c7fd", "url": "https://github.com/zls3434/quick-input/blob/4f48bbd849b63514812e8ef32a94a4fe19b9c7fd/.windsurf/workflows/day-one-patch.md", "key": "zls3434/quick-input/.windsurf/workflows/day-one-patch.md" } } }

day-one-patch

About