Back to Details

diagnose

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Diagnose

诊断

Use this workflow only after the explicit opt-in described in the frontmatter. A normal bug report or debugging request does not opt in to this skill.
Find and explain the cause of a symptom with 100% operational confidence.
Start from the user's concrete anchor: file, route, error, log, screen, branch, artifact, or reproduction step. Consult relevant architecture notes, ADRs, glossaries, and test docs. Inspect code, run safe tools or tests, and analyze existing artifacts.
Explicit invocation of Diagnose constitutes approval for behavior-neutral temporary instrumentation within the requested scope. Ask separately only for risky actions, inaccessible-state reproduction, or mutations that affect product behavior or external systems.
仅在前置说明中描述的用户显式同意后，才可使用此工作流。普通的bug报告或调试请求并不意味着同意使用该skill。
找到并以100%的操作置信度解释症状的原因。
从用户提供的具体锚点入手：文件、路由、错误、日志、界面、分支、工件或复现步骤。查阅相关的架构说明、ADRs、术语表和测试文档。检查代码、运行安全工具或测试，并分析现有工件。
用户显式调用Diagnose即表示同意在请求范围内进行行为中立的临时插桩操作。仅在涉及风险操作、无法访问的状态复现、或会影响产品行为或外部系统的变更时，才需要单独询问用户。

References

参考资料

Load only what applies:
  • Browser or React web: browser-react.md
  • iOS, Android, React Native, macOS, TV, or physical device: app-device.md
  • Logs, runtime probes, metrics, or debug hooks: instrumentation.md
仅加载适用的内容：
  • 浏览器或React网页：browser-react.md
  • iOS、Android、React Native、macOS、TV或物理设备：app-device.md
  • 日志、运行时探针、指标或调试钩子：instrumentation.md

Evidence Loop

证据循环

  1. Locate likely causes. Inspect the code path and existing evidence around the user's anchor. Form the smallest useful set of likely areas and falsifiable candidate causes, including independent or contributing causes when applicable. Give each cause a distinguishing prediction and identify where those predictions diverge.
  2. Instrument before reproducing. Load instrumentation.md and add structured logging across the relevant boundaries, extensive enough to reconstruct the causal sequence rather than only record the visible symptom. Instrument competing causes in the same pass when practical so one reproduction can distinguish them.
    Before reproducing, define the probe contract:
    • the exact trigger and visible symptom
    • the questions this run will answer
    • each candidate cause's distinguishing prediction
    • the events, fields, and correlation IDs that test those predictions
    • how the evidence will be tied to the exact visible failure
    • the intended process, build, window, document, and runtime identity when applicable
    Do not run the reproduction if the probes cannot distinguish the leading candidates or cannot confirm that the exact symptom occurred.
  3. Reproduce the instrumented issue. Use the fastest deterministic signal that represents the reported symptom: focused test, script, browser test, trace replay, harness, repeat loop, profiler, app/device automation, or structured human reproduction. Run it when safe and observable. For intermittent failures, run enough repetitions to compare causes.
    When reproduction requires inaccessible state, credentials, devices, subjective interaction, or risky actions, first prepare the capture, exact steps, expected observation, and artifact to inspect. Ask the user to reproduce and reply 
    done
    ; confirm the returned evidence matches the reported failure.
    If the user corrects the trigger, affected component, lifecycle, or visible symptom, invalidate evidence and probes that target the previous interpretation. Return to cause location and instrumentation before reproducing again; do not continue with a nearby but mismatched reproduction.
  4. Collect and analyze. Collect the complete output, correlate events across boundaries, compare it with each prediction, and record evidence for and against every cause. If the logs are incomplete or ambiguous, identify how the likely areas or instrumentation must change before another reproduction.
  5. Determine confidence. Rank each cause by role (root, contributing, or alternative), 
    0-100%
    confidence, supporting and conflicting evidence, and the next evidence that could change its score or rank. Treat scores as calibrated judgments, not statistical probabilities. Assign 100% operational confidence only when:
    • the exact symptom is reproduced
    • the causal chain from trigger to failure is observed
    • controlling the suspected boundary reliably controls the symptom
    • the cause or combination of causes explains every relevant observation
    • plausible alternatives are falsified or included as contributing causes
    • intermittent behavior is repeated enough to distinguish causality from coincidence
    If proof is incomplete, choose the safest practical probe likely to add discriminating evidence and state which results would raise, lower, or redistribute confidence. Revise the likely areas or instrumentation and repeat the loop only while such a probe exists; do not repeat an equivalent pass without changing its inputs, boundary, or instrumentation.
    Stop as incomplete when no available probe should increase confidence, a pass adds no evidence and no distinct boundary remains, or the needed evidence requires unavailable access, user action, unacceptable risk, or disproportionate effort. Never label an incomplete diagnosis as proven.
  1. 定位可能的原因。检查用户锚点周围的代码路径和现有证据。形成最小且有用的可能区域集合以及可证伪的候选原因，必要时包括独立原因或促成原因。为每个原因赋予独特的预测，并确定这些预测的分歧点。
  2. 复现前插桩。加载instrumentation.md，在相关边界添加结构化日志，日志需详尽到足以重建因果序列，而非仅记录可见症状。若可行，在同一步骤中对竞争原因进行插桩，以便一次复现即可区分它们。
    复现前，需定义探针契约：
    • 确切的触发条件和可见症状
    • 本次运行要解答的问题
    • 每个候选原因的独特预测
    • 用于验证这些预测的事件、字段和关联ID
    • 如何将证据与确切的可见故障关联起来
    • 适用时的预期流程、构建版本、窗口、文档和运行时标识
    若探针无法区分主要候选原因，或无法确认确切症状是否发生，则不得运行复现操作。
  3. 复现已插桩的问题。使用最能代表报告症状的最快确定性信号：聚焦测试、脚本、浏览器测试、追踪重放、测试harness、重复循环、性能分析器、应用/设备自动化或结构化人工复现步骤。在安全且可观测的情况下运行。对于间歇性故障，需运行足够次数以对比不同原因。
    若复现需要无法访问的状态、凭据、设备、主观交互或风险操作，需先准备好捕获方案、确切步骤、预期观测结果和待检查的工件。请用户进行复现并回复
    done
    ；确认返回的证据与报告的故障匹配。
    若用户更正了触发条件、受影响组件、生命周期或可见症状，则需作废针对之前解释的证据和探针。返回原因定位和插桩步骤，之后再进行复现；不得继续使用相近但不匹配的复现操作。
  4. 收集与分析。收集完整输出，跨边界关联事件，将其与每个预测进行对比，并记录支持和反对每个原因的证据。若日志不完整或存在歧义，需确定在下次复现前需如何调整可能的区域或插桩方式。
  5. 确定置信度。按作用（根本原因、促成原因或替代原因）、
    0-100%
    置信度、支持和冲突证据、以及可能改变其分数或排名的下一项证据，对每个原因进行排序。将分数视为校准后的判断，而非统计概率。仅在满足以下条件时，才可赋予100%的操作置信度：
    • 确切症状已被复现
    • 已观测到从触发到故障的因果链
    • 控制可疑边界可可靠地控制症状
    • 该原因或原因组合可解释所有相关观测结果
    • 合理的替代原因已被证伪或被列为促成原因
    • 间歇性行为已重复足够次数，可区分因果关系与巧合
    若证据不完整，选择最安全且可能增加鉴别证据的可行探针，并说明哪些结果会提高、降低或重新分配置信度。仅当存在此类探针时，才修改可能的区域或插桩方式并重复循环；不得在未改变输入、边界或插桩方式的情况下重复相同步骤。
    当没有可用探针可提升置信度、某次操作未增加证据且无剩余独特边界、或所需证据需要无法获取的访问权限、用户操作、不可接受的风险或不成比例的工作量时，需终止并标记为未完成。不得将未完成的诊断标记为已证实。

Output

输出结果

Lead with one status:
  • Proven — 100%: every applicable cause meets the proof standard with no unresolved plausible alternative.
  • Incomplete: the proof standard is not met.
For Proven, report each cause, role, causal chain, decisive evidence, exact code or runtime boundary, and interaction between causes. For Incomplete, rank candidates with confidence, supporting and conflicting evidence, remaining uncertainty, why the loop stopped, and the smallest evidence needed to continue. Always name the validation signal that preserves the causal evidence.
首先给出一个状态：
  • 已证实 — 100%：所有适用原因均符合验证标准，无未解决的合理替代原因。
  • 未完成：未达到验证标准。
对于已证实的情况，需报告每个原因、作用、因果链、决定性证据、确切的代码或运行时边界，以及原因之间的相互作用。对于未完成的情况，需按置信度对候选原因排序，列出支持和冲突证据、剩余不确定性、循环终止的原因，以及继续诊断所需的最小证据。始终指明保留因果证据的验证信号。

Temporary Diagnostics

临时诊断信息

Keep diagnostic logs until the user requests cleanup or they become durable diagnostics. If committing while temporary diagnostics remain, stage only intended durable changes and report what remains unstaged.
保留诊断日志，直到用户请求清理或它们成为持久诊断信息。若在临时诊断信息仍存在时提交代码，仅暂存预期的持久变更，并报告未暂存的内容。

Delegation

委托

Use subagents only when the user explicitly requests delegation, subagents, parallel work, or token optimization. Delegate bounded mechanical collection to faster or cheaper agents: known commands or repro loops, logs, screenshots, traces, profiles, extraction, or artifact comparison. Give each task a success condition, output format, runtime boundary, and no-edit instruction unless mutation is explicit.
Keep feedback-loop design, hypothesis ranking, confidence scoring, ambiguous interpretation, and the final diagnosis in the main thread. Verify delegated evidence and inspect the working tree and background processes before continuing.
仅当用户明确请求委托、子代理（subagents）、并行工作或令牌优化时，才可使用子代理。将有界的机械性收集工作委托给更快或更廉价的代理：已知命令或复现循环、日志、截图、追踪、性能分析、提取或工件比较。为每个任务设定成功条件、输出格式、运行时边界，除非明确允许变更，否则需添加禁止编辑的指令。
将反馈循环设计、假设排序、置信度评分、歧义解释以及最终诊断保留在主线程中。在继续之前，需验证委托获取的证据，并检查工作树和后台进程。