菜单
Diagnose root cause from logs, errors, stack traces, failing outputs, code, and config. Diagnosis only; no fixing by default. Use when the user wants a root cause hypothesis, an evidence assessment of a proposed fix, or a verification plan.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | bug-investigation |
| description | Diagnose root cause from logs, errors, stack traces, failing outputs, code, and config. Diagnosis only; no fixing by default. Use when the user wants a root cause hypothesis, an evidence assessment of a proposed fix, or a verification plan. |
Diagnose root cause from available evidence. Separate confirmed from suspected. Do not edit files. Output a verification plan that someone else can execute.
Workflow phases:
scope -> evidence collection -> hypotheses -> root cause assessment -> missing evidence -> fix direction -> verification plan
Evidence first. Start from attached logs, stack traces, error messages, failing outputs, and provided code. Identify the failure mode in concrete terms (input, expected, observed) before forming hypotheses.
Hypothesis discipline. Generate at least two hypotheses when the evidence is ambiguous. For each, list supporting evidence, contradicting evidence, and the cheapest discriminator. Reject hypotheses that explain only some of the symptoms.
Classification. Every hypothesis ends in one of: confirmed (supported by direct evidence), suspected (consistent with evidence but not proven), unverified (cannot be assessed from available evidence). Do not promote suspected to confirmed without new evidence.
Fix direction, not the fix. Sketch the smallest plausible change direction at the level of contract, control flow, data, or configuration. Do not write the patch. Note refactor risk, blast radius, and reversibility.
suspected instead.confirmed, suspected, and unverified.Use only sections that matter.
bug-context: reported symptom, observed vs expected, when it started, scope (one user, many users, one environment, all).
evidence-reviewed: logs, traces, code snippets, commits, config, or attachments examined; cite paths or attachment names.
hypotheses: each with supporting evidence, contradicting evidence, discriminator, classification (confirmed|suspected|unverified).
most-likely-root-cause: single statement with classification and why it explains all observed symptoms.
missing-evidence: data, logs, repro steps, or code paths needed to raise confidence.
fix-direction: smallest plausible change, alternatives, blast radius, reversibility.
verification-plan: concrete steps to confirm the diagnosis, reproduce the bug, and verify a fix. Include commands or test ideas the executor can run.
status: diagnosed, partially diagnosed, or blocked.
End each response with: scope, confidence (high|medium|low), status, key assumptions or missing evidence, next-step (only if useful).
Format responses in plain Markdown using simple headings, bullets, and fenced code blocks.
Prefer purpose-built filesystem and text tools over shell, batch independent calls, and use safe edit locators.
Use attached and local context first, separate observed facts from inferred conclusions, and cite source paths.
Generate one Mermaid diagram plus concise commentary.
Implementation plan and snippets for the specified React stack.
Scaffold idiomatic table-driven tests for a given function.