用途：并行修复多个相互独立的问题。先对问题分类并确认彼此无共享文件，再为每个子代理分配严格的文件所有权，独立修复后统一审查合并。
主要能力与流程：问题分析（用 debugger 子代理定位根因、用 /scout-ext 查找相关文件、按前端/后端/认证/支付等归类并识别依赖）；并行修复规划（触发 /plan-parallel，产出依赖图、执行策略与文件所有权矩阵）；并行实现（同时启动多个 fullstack-developer 代理，依赖项串行）；测试（tester 子代理跑完整测试，禁止假数据/mock）；代码审查（先 spec-compliance-reviewer 再 code-reviewer）；项目管理与文档；用 /prove-fix 逐项证明修复；最终报告并询问是否提交。
关键规则：动手前必须先读现有代码，搜索 3+ 相似模式并引用 file:line 证据；存在 .code-graph/graph.db 时运行 python .claude/scripts/code_graph trace <file> --direction both --json；非平凡任务把调查写入 .ai/workspace/analysis/；每个代理把发现写入 .ai/workspace/analysis/{issue-name}-{agent}.analysis.md。禁止臆测，每条结论需证据与置信度（>80% 可行动，60-80% 先验证，<60% 不建议）。修改前须经 AskUserQuestion 获得用户明确批准。
限制与停止条件：问题必须独立、无重叠文件修改；置信度低于 60%、影响超过 20 个文件、跨服务边界、涉及安全敏感代码、破坏性变更、测试覆盖率下降或需引入项目外技术时，须停下并升级给用户。连续 3 次修复失败后停止并报告。涉及 .ts/.html/.scss/.css 时须先读前端模式、SCSS 与设计系统参考文档。
其他：估算采用修正斐波那契（1/2/3/5/8/13/21），SP>8 应拆分；计划 frontmatter 需含 story_points 与 complexity。若在工作流外调用，须用 AskUserQuestion 让用户选择继续完整流程、/prove-fix、/test 或手动继续。