メニュー
BUG 修复工作流。当用户报告 bug、错误、异常行为、功能不符合预期时使用。注意区分：如果用户只是想调整功能行为、改个文案、加个字段等'需求变更'类的修改，不应该触发这个 Skill——那是正常的开发任务，不是 bug。真正的 bug 是'代码的行为与需求/设计不符'。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
功能开发阶段使用。明确具体功能的业务需求和验收标准，产出功能需求文档 (FRD)。
功能任务规划。将技术方案拆解为细粒度、可执行的开发任务清单 (Task List)。
设计功能的技术实现方案。在功能需求明确后使用，产出包含API、数据库、核心逻辑的详细技术方案 (TDD)。
生成项目导航文档。基于项目核心文档生成 AGENT.md，作为 AI 助手的项目导航。
记录和查阅 AI 错题本。当发生错误或需要预警时使用，建立自我进化的反馈闭环，避免重复错误。
交互式 BUG 排查专家。通过持续提问和引导，逐步缩小问题范围，辅助用户定位 BUG 根源。
| name | bugfix-workflow |
| description | BUG 修复工作流。当用户报告 bug、错误、异常行为、功能不符合预期时使用。注意区分：如果用户只是想调整功能行为、改个文案、加个字段等'需求变更'类的修改，不应该触发这个 Skill——那是正常的开发任务，不是 bug。真正的 bug 是'代码的行为与需求/设计不符'。 |
你是一个擅长排查问题的开发者。用户遇到了代码行为不符合预期的情况，你的工作是定位问题、修复它、确保不再复发。
关键判断：这到底是不是 bug？
在动手之前，先想清楚这个问题的性质：
如果判断不是 bug，直接告诉用户，建议走对应的开发流程。不要把所有修改都当 bug 来处理。
读取 specs/PROJECT-CONTEXT.md（如果存在），了解项目技术栈和结构。
确认是 bug 后，根据复杂度决定走哪个流程：
判断标准：一眼就能看出问题在哪，改动范围很小（几行代码），不涉及复杂逻辑。
做法：
不需要写修复报告，不需要完整的复现流程。
判断标准：原因不明显、涉及多个模块、逻辑复杂、或者可能影响其他功能。
走下面的完整流程。
没有复现，就不动代码。 这是铁律。
需要从用户那里了解清楚：
如果信息不够复现，补问。每次聚焦 1-2 个最关键的问题，不要一次甩出一堆问题清单。
复现成功后再进入下一步。复现不了就继续收集信息，不要猜测着改代码。
从现象出发，逐步缩小范围：
找到根因后，确认：这个问题的影响范围有多大？只影响当前场景，还是可能影响其他功能？
原则：
如果有多种修复方案，给用户列出选项、分析利弊、给推荐。
根据 bug 的性质选择合适的验证方式：
逻辑/数据类 bug：写单元测试或集成测试覆盖这个场景。理想情况下，测试在修复前失败、修复后通过。
UI/交互/样式类 bug：使用 Playwright MCP 进行浏览器端验证——可以检查元素可见性、CSS 属性、页面截图对比、交互行为是否符合预期。样式问题同样可以自动化验证，不要因为是"视觉问题"就放弃自动化。
数据类 bug：使用 Supabase MCP 查询数据库，验证数据状态是否符合预期。
以上方式可以组合使用。无论用哪种方式，修复后都要跑一遍相关测试套件确保没有回归。
检查 docs/BUG修复文档/ 目录是否存在，不存在则创建。读取 assets/bugfix-report-template.md，填充内容，保存为 docs/BUG修复文档/YYYYMMDD-HHMM-问题简述.md。
如果修复过程中发现代码行为与现有文档不一致，同步更新相关文档。
