在需要反复诊断并修复问题时…

当你被要求持续调试、修复并验证、迭代到满意，或在诊断后继续改进时，用诊断技能驱动一个完整的诊断-修复-再诊断循环。

适用场景

解决思路

1. 开始前先加载并遵循 $diagnose，把它当作每一轮的证据引擎；本技能只负责外层的计划、实现、重新诊断和是否继续的决策。
2. 如果 $diagnose 未安装或不可用，在做出任何修改前停止，并让用户用 `npx skills add LegendApp/legend-skills --skill diagnose` 安装后重试。
3. 第 1 步：明确目标结果。把循环锚定到用户的症状、性能目标、失败测试、UX 缺陷、回归或代码质量问题上；如果用户没有给出具体锚点，先创建最快的可观察反馈回路。
4. 第 2 步：运行一次 $diagnose。完成证据回路，并记录修复后要重新运行的精确验证信号。只有当 $diagnose 报告 **Proven — 100%** 时才继续；如果报告 **Incomplete**，停止并报告缺失的证据。如果用户要求委派，只在本轮内用于有边界的证据收集；瓶颈排序、修复选择、代码编辑和最终解释仍留在主循环中。
5. 第 3 步：制定按优先级排序的修复计划。优先一次只做一个最小可信修复。计划必须包含：哪些证据支持该改动、将改动哪个文件或边界、哪个验证应改善、什么情况会使该计划不成立。
6. 第 4 步：只实现计划中优先级最高的那一项。把编辑限制在已证实的故障线上；避免堆叠推测性清理、大范围重构或相邻改进，除非诊断表明它们属于同一故障。
7. 第 5 步：用原始信号验证。重新运行第 2 步的复现路径或测量，然后运行聚焦的回归覆盖，再在触及面需要时运行更广泛的检查。
8. 第 6 步：重新运行 $diagnose。基于证据而非改动意图来诊断新状态，寻找：原始症状仍然失败、附近仍有故障、修复引入的回归、第一次修复暴露出的更强下一个瓶颈、真实接缝处缺失的覆盖。
9. 第 7 步：决定是否继续。当证据指出下一个可信修复且下一步操作安全时继续；每次新迭代都应比上一次有更精确的目标。
10. 迭代过程中维护一个简短日志：迭代编号、当前证据、所选修复、验证结果、下一个剩余问题或停止原因。
11. 如果某个实验失败，除非它独立有用且有意保留，否则回退它；除非失败实验缩小了诊断范围，否则不要把它算作进展。
12. 如果两次迭代没有产生可测量的改进，也没有更精确的证据，暂停实现，先重新诊断反馈回路本身，再做更多编辑。
13. 仅在以下情况之一成立时停止：$diagnose 无法用现有代码、工具或产物构建或运行可信反馈回路；下一步需要用户输入、不可访问的外部状态、凭据、生产访问或破坏性操作；用户要求只读诊断而下一步有用操作会编辑文件；验证干净且新的 $diagnose 未发现剩余可信故障；剩余改进是推测性、表面性的或超出用户目标结果。
14. 停止时报告最终状态、验证证据、已知剩余风险，以及如果工作被阻塞所需的最小用户操作或产物。

适用边界 · 注意事项

• 未安装 $diagnose 技能时（必须先安装 diagnose 才能使用本循环）。
• 用户要求只读诊断、不允许编辑文件时。
• 下一步需要用户输入、凭据、生产访问或破坏性操作时。