diagnose-fix-loop

诊断修复循环

使用此技能推动完整的改进循环，而不是只进行一次调试。

开始前，先加载并遵循 $diagnose。每轮都将 $diagnose 作为证据引擎；此技能只负责规划、实施、重新运行诊断并决定是否继续的外层循环。

明确调用即表示选择使用 $diagnose，并授权进行范围明确的本地修复和验证。当证据支持可信的原因和修复方案后，此技能负责实施。

选定的安装方式不会自动安装依赖。如果未安装或无法使用 $diagnose，请在修改前停止。告知用户使用以下命令安装：

npx skills add LegendApp/legend-skills --skill diagnose

然后请用户安装后重试。

循环

1. 说明目标结果。 围绕用户提到的症状、性能目标、失败测试、UX 缺陷、回归问题或代码质量问题来开展循环。如果用户没有提供明确的切入点，先建立最快速、可观察的反馈循环。

2. 运行一轮 $diagnose。 记录因果证据，以及修复后要重新运行的确切验证信号。若证据达到 Proven 或 Supported，足以支持范围明确的修复，则继续。如果证据仍为 Incomplete，继续执行有用且可用的探查；当缺失的证据导致无法提出可信修复时，停止并报告这一缺口。 如果用户要求委派任务，只能在本轮中委派范围明确的证据收集工作；瓶颈排序、修复方案选择、代码编辑和最终解读仍由主循环负责。

3. 制定按优先级排序的修复计划。 优先一次只做一个最小且可信的修复。计划必须包含：

   • 支持此次更改的证据
   • 将要更改的文件或边界
   • 预期改善的验证结果
   • 哪些情况会表明计划有误

4. 只实施计划中优先级最高的一项。 将改动限制在有证据支持的因果边界内。避免叠加推测性的清理、大范围重构或相邻改进，除非诊断已表明它们属于同一故障。

5. 使用原始信号进行验证。 重新运行第 2 步中的复现路径或测量，然后运行针对性的回归测试；如果所改动的范围有此需要，再运行更广泛的检查。

6. 重新运行 $diagnose。 根据证据诊断当前状态，而不是根据改动的意图。检查：

   • 原有症状是否仍然存在
   • 附近是否还存在其他故障
   • 修复是否引入回归
   • 首次修复是否暴露出更突出的下一个瓶颈
   • 实际衔接点是否缺少测试覆盖

7. 决定是否继续。 当证据指出可信的下一项修复，且下一步操作安全时，继续。每次新迭代的目标都应比上一次更明确。

迭代规范

工作期间，持续记录简短日志：

• 迭代编号
• 当前证据
• 选定的修复方案
• 验证结果
• 下一个待解决问题或停止原因

如果实验失败，除非它本身有用且决定保留，否则应回滚。如果失败的实验没有缩小诊断范围，就不要将其算作进展。

如果连续两轮没有带来可衡量的改进，也没有获得更明确的证据，请暂停实施，在继续修改前重新诊断反馈循环本身。

停止规则

仅在符合以下任一条件时停止：

• 使用现有代码、工具或产物，$diagnose 无法构建或运行可信的反馈循环
• 下一步需要用户输入、无法访问的外部状态、凭据、生产环境访问权限或破坏性操作
• 用户要求只读诊断，而下一步有用操作需要编辑文件
• 验证通过，且新一轮 $diagnose 未发现仍有可信修复方案的故障
• 剩余改进仅属推测、表面优化，或超出用户的目标范围

停止时，报告最终状态、验证证据、已知的剩余风险，以及在工作受阻时用户所需采取的最小操作或提供的产物。