系统化调试修复 Bug。五阶段：收集证据→重现用例→分析(含根因归因)→假设→修复→进化记录。支持触发 code-review 和 feedback-writer。
系统化调试修复 Bug。五阶段：收集证据→重现用例→分析(含根因归因)→假设→修复→进化记录。支持触发 code-review 和 feedback-writer。
npx skills add https://github.com/Herxinsasa/Product-Manager --skill bug-fixer复制此命令并粘贴到 Claude Code 中以安装该技能
构建验证、版本管理与发布上线。多轮确认发布目标与推送路径后执行门禁与发布，写入状态与 release notes。用户提到发布、上线、deploy、打 tag、发版、merge 到 main、推远程、构建生产包、创建 PR 时，即使未说 release 也必须使用本 skill。
技术架构设计。调研技术方案、评估开源项目、输出架构决策记录，写入 Tech-Arch.md。在 dev-planner 之前调用。
设计执行。基于 Design-Brief.md 产出原型、设计稿或设计系统。支持 Figma、Pencil、HTML/CSS 原型等多种输出方式。
需求收集与问题澄清。新建或迭代 PRD，通过交互式澄清生成结构化产品需求文档。
代码审查和质量检查。调度 code-reviewer sub-agent 审查代码，检查是否符合计划和编码标准。
根据开发计划编写代码。按任务调度 implementer sub-agent，在 <project-name>/ 目录下创建项目。
| name | bug-fixer |
| description | 系统化调试修复 Bug。五阶段：收集证据→重现用例→分析(含根因归因)→假设→修复→进化记录。支持触发 code-review 和 feedback-writer。 |
系统化地调试和修复 Bug。核心原则是 先调查根本原因，再尝试修复。禁止在看到报错后立即猜测性修改。
不找出根本原因就不允许修复
如果还没完成阶段 1（证据收集），就不能进入阶段 4（修复）。
仔细阅读错误信息
稳定复现
检查最近的变更
git diff 和最近的 commits收集完整上下文
将证据转化为可重现的测试或复现脚本。
| 根因类型 | 定义 | 举例 |
|---|---|---|
| 需求遗漏 | PRD/验收标准没写清楚，导致理解偏差 | "没说空状态要怎么展示" |
| 设计遗漏 | 设计规范/ADR 未覆盖该场景 | "设计稿没有错误态的样式" |
| 编码失误 | 需求设计都明确，实现写错了 | "循环里漏了 break" |
| 边界遗漏 | 正常路径对但极端输入/并发/超时未处理 | "文件超过 1GB 时 OOM" |
1. 写入文档错误记录表
将 Bug 追加到对应文档的「决策与错误记录 > 错误与修复」表：
| 错误 | 影响 | 根因类型 | 修复方式 | 日期 |
|------|------|---------|---------|------|
| <Bug 描述> | <影响范围> | 需求遗漏/设计遗漏/编码失误/边界遗漏 | <修复摘要> | YYYY-MM-DD |
Product-Spec.mdDesign-Brief.mdDev-Plan.md2. 触发进化反馈
如果根因类型是编码失误或设计遗漏，调用 feedback-writer，记录结构化反馈：
feedback 内容：
- type: "correction"
- skill: 受影响的 skill（product-spec-builder / design-brief-builder / implementer 等）
- context: "Bug 修复中发现：<根因类型>"
- issue: "<具体问题描述>"
- resolution: "<修复方式>"
这样进化引擎才能在后续扫描到同一模式出现 ≥3 次时，触发对应 Skill 的优化提案。
3. 判断是否需要 code-review
修复完成后，判断以下条件：
更新 .claude/progress.json：
milestones 追加「Bug 修复：<摘要>（根因：<类型>）」