bugfix-quick 是一套供 AI 编码代理在执行期间阅读的快速缺陷修复参考流程，来源为 nguyenthienthanh/archon。它只适用于缺陷修复，功能开发和重构类任务应改走 run-orchestrator。
核心原则是“没有根因就不修复”，要求修复问题源头而不是只消除表面症状。整个流程分为四个步骤，每一步都要向用户宣告，并同步更新状态行与 run-state.json 中的 current_step（取值 investigate、test-red、fix-green、verify）和 active_agent。
第一步是调查：阅读错误信息与堆栈，复现缺陷，用 git log、git diff 查看近期改动，并反向追溯坏数据的来源。文档强调上下文节约：先用 Grep 查找失败符号，再用 offset 与 limit 只读取匹配行，除非缺陷横跨整个文件，否则不要通读。
第二步是编写失败测试（RED）：写出能精确复现缺陷的测试，并按 test-writer 技能的测试类型选择确定层级。UI、用户流程、认证或支付相关的回归应通过 Playwright MCP 写 e2e 用例，而不是写无法真正复现问题的单元测试；纯逻辑缺陷则用单元测试。测试必须因正确的原因失败，并由用户确认失败。
第三步是修复（GREEN）：在根因处做最小、聚焦的改动，由用户确认测试通过。第四步是验证：运行完整测试套件；若第二步写了 e2e 用例，还要运行 npx playwright test 或 npx cypress run，确保两者均无回归。文档要求先读输出再下结论，“测试通过”若没有通过数量，可能意味着收集到 0 个测试。
输出格式包含缺陷描述、根因、新增测试（文件与测试名）、修复内容（文件与改动摘要）以及验证结果。若问题复杂，应切换到 run-orchestrator；若缺陷顽固（偶发、竞态、仅在特定机器复现、存在多个可能原因），则升级到 deep-debugging 技能做科学方法式的根因分析。文档还列出危险信号，如“先快速修一下”“试试改 X”“大概是 X”“看起来修好了”，出现时应退回第一步。相关规则涉及 TDD 工作流、验证规则、执行规则和简洁优先原则。
关于收费、价格、平台支持范围等信息，资料暂未提供。