القائمة
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。
如果修复过程中发现代码行为与现有文档不一致，同步更新相关文档。
