Back to Details

diagnose-fix-loop

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Diagnose Fix Loop

Diagnose Fix Loop 诊断修复循环

Use this skill to drive a complete improvement loop, not a single debugging pass.
Before starting, load and follow 
$diagnose
. Treat 
$diagnose
as the evidence engine for each pass; this skill only adds the outer loop that plans, implements, re-runs diagnosis, and decides whether to continue.
This skill owns planning and implementation after 
$diagnose
proves the cause.
Selected installs do not install dependencies automatically. If 
$diagnose
is not installed or available, stop before making changes. Tell the user to install it with:
bash
npx skills add LegendApp/legend-skills --skill diagnose
Then ask them to retry after installation.
使用该skill来驱动完整的改进循环，而非单次调试过程。
开始前，请加载并遵循
$diagnose
规范。将
$diagnose
视为每一轮循环的证据引擎；本skill仅负责添加外层循环，用于规划、执行改进、重新运行诊断以及决定是否继续循环。
在
$diagnose
确认问题原因后，由本skill负责规划和执行改进操作。
所选安装不会自动安装依赖项。如果
$diagnose
未安装或不可用，请在进行更改前停止操作。告知用户通过以下命令安装：
bash
npx skills add LegendApp/legend-skills --skill diagnose
然后请用户安装完成后重试。

Loop

循环流程

  1. State the target outcome. Anchor the loop to the user's symptom, performance goal, failing test, UX defect, regression, or code quality concern. If the user gave no concrete anchor, create the fastest observable feedback loop first.
  2. Run a 
    $diagnose
    pass. Complete the evidence loop and record the exact validation signal that will be re-run after the fix. Proceed only when 
    $diagnose
    reports Proven — 100%. If it reports Incomplete, stop and report the missing evidence. If the user asked for delegation, use it only for bounded evidence collection inside this pass; keep bottleneck ranking, fix selection, code edits, and final interpretation in the main loop.
  3. Make a ranked fix plan. Prefer one smallest credible fix at a time. The plan must include:
    • what evidence supports the change
    • what file or boundary will change
    • what validation should improve
    • what would make the plan wrong
  4. Implement only the top plan item. Keep the edit scoped to the proven fault line. Avoid stacking speculative cleanup, broad refactors, or adjacent improvements unless the diagnosis showed they are part of the same fault.
  5. Verify with the original signal. Re-run the reproduction path or measurement from step 2, then focused regression coverage, then broader checks when the touched surface warrants them.
  6. Re-run 
    $diagnose
    . Diagnose the new state from evidence, not from the intent of the change. Look for:
    • the original symptom still failing
    • a nearby remaining fault
    • a regression introduced by the fix
    • a stronger next bottleneck revealed by the first fix
    • missing coverage at the real seam
  7. Decide whether to continue. Continue when evidence identifies a credible next fix and the next action is safe to take. Each new iteration should have a sharper target than the previous one.
  1. 明确目标结果。 将循环锚定到用户提出的症状、性能目标、测试失败、UX缺陷、回归问题或代码质量问题。如果用户未提供具体锚点，先创建最快的可观测反馈循环。
  2. 运行一轮
    $diagnose
    。 完成证据循环，并记录修复后将重新运行的精确验证信号。仅当
    $diagnose
    报告Proven — 100%时才可继续。如果报告Incomplete，请停止操作并告知缺失的证据。 如果用户要求委托处理，仅可将其用于本轮循环内的有限证据收集；瓶颈排序、修复方案选择、代码编辑以及最终解读需保留在主循环中进行。
  3. 制定排序后的修复计划。 优先选择单次最小可行的修复方案。计划必须包含：
    • 支持该更改的证据
    • 将更改的文件或边界
    • 应得到改善的验证项
    • 证明该计划错误的条件
  4. 仅执行排名第一的计划项。 编辑范围需限定在已确认的故障点内。除非诊断显示这些操作属于同一故障的一部分，否则避免进行推测性清理、大范围重构或相邻改进。
  5. 使用原始信号进行验证。 重新运行步骤2中的复现路径或测量，然后进行针对性的回归覆盖，当涉及范围较广时再进行更全面的检查。
  6. 重新运行
    $diagnose
    。 根据证据诊断新状态，而非基于更改的意图。检查以下内容：
    • 原始症状是否仍存在
    • 是否存在附近未解决的故障
    • 修复是否引入了回归问题
    • 首次修复是否暴露了更严重的下一个瓶颈
    • 实际接口处是否存在覆盖缺失
  7. 决定是否继续循环。 当证据确定存在可行的下一个修复方案且下一步操作安全时，继续循环。每一次新迭代的目标应比上一次更明确。

Iteration Discipline

迭代准则

Keep a short running log while working:
  • iteration number
  • current evidence
  • chosen fix
  • validation result
  • next remaining issue or stop reason
If an experiment fails, revert it unless it is independently useful and intentionally kept. Do not count a failed experiment as progress unless it narrowed the diagnosis.
If two iterations produce no measurable improvement and no sharper evidence, pause implementation and re-diagnose the feedback loop itself before making more edits.
工作时需保留简短的运行日志：
  • 迭代次数
  • 当前证据
  • 所选修复方案
  • 验证结果
  • 下一个未解决问题或停止原因
如果实验失败，除非该更改本身有用且有意保留，否则请回滚。除非实验缩小了诊断范围，否则不要将失败的实验视为进展。
如果两次迭代均未产生可衡量的改进或更明确的证据，请暂停执行，先重新诊断反馈循环本身，再进行更多编辑。

Stop Rules

停止规则

Stop only when one of these is true:
  • $diagnose
    cannot build or run a credible feedback loop with available code, tools, or artifacts
  • the next action requires user input, inaccessible external state, credentials, production access, or a destructive operation
  • the user requested read-only diagnosis and the next useful step would edit files
  • validation is clean and a fresh 
    $diagnose
    pass finds no remaining credible fault to fix
  • remaining improvements are speculative, cosmetic, or outside the user's target outcome
When stopping, report the final state, the validation evidence, remaining known risk, and the smallest user action or artifact needed if work is blocked.
仅在以下任一情况满足时停止：
  • $diagnose
    无法利用现有代码、工具或工件构建或运行可信的反馈循环
  • 下一步操作需要用户输入、无法访问的外部状态、凭证、生产环境访问权限或破坏性操作
  • 用户要求仅进行只读诊断，而下一步有用操作需要编辑文件
  • 验证结果正常，且新运行的
    $diagnose
    未发现任何剩余可信故障需要修复
  • 剩余改进方案具有推测性、仅为美化或超出用户的目标结果范围
停止时，请报告最终状态、验证证据、已知剩余风险，以及如果工作受阻所需的最小用户操作或工件。