菜单
Root-cause a bug through a disciplined 6-phase loop — build a feedback loop, reproduce, rank falsifiable hypotheses, instrument, fix with a regression test, then clean up and post-mortem. Use for "/diagnose", "debug this", "find the root cause".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | diagnose |
| description | Root-cause a bug through a disciplined 6-phase loop — build a feedback loop, reproduce, rank falsifiable hypotheses, instrument, fix with a regression test, then clean up and post-mortem. Use for "/diagnose", "debug this", "find the root cause". |
| argument-hint | [the bug or failing behavior] |
| model | inherit |
| allowed-tools | Read, Edit, Write, Grep, Glob, Bash |
Root-cause the bug in $ARGUMENTS by evidence, not by guessing. Work the six phases in order;
don't skip ahead to a fix before the cause is proven. Reuse the project's TDD discipline and its
done-check (its tests, linter, type-checker) rather than restating them.
Find or establish the fastest reliable way to observe the bug: a failing test, a one-line script, a single command. Everything after this rests on the loop being quick and deterministic, so invest here first.
Make the bug happen on demand through that loop. If you can't reproduce it, say so and gather more signal (logs, inputs, environment) — do not start fixing a bug you can't trigger.
Write 3–5 ranked, falsifiable hypotheses for the root cause. Each must predict something you can check ("if it's X, then Y will be true"). Rank by likelihood × cheapness-to-test, cheapest decisive check first.
Add targeted logging / asserts / breakpoints to confirm or kill hypotheses one at a time, top-ranked first. Let the evidence pick the cause; don't pattern-match to a fix. Keep going until exactly one hypothesis survives and you've seen it cause the failure.
Once the cause is proven:
Remove the instrumentation you added, confirm the done-check is still green, then give a 2–3 line post-mortem: root cause, why it hid, and what the regression test now guards.
Honesty rules: never claim a fix you haven't watched pass the loop. If the cause stays unproven, report the surviving hypotheses and what you'd check next — don't ship a guess.
Run one task through the plan→build→review pipeline — a Step-0.5 classify-task call routes the planner/implementer/reviewer models to the task's complexity tier, then the plan is written (planner subagent or inline), the implementer builds it in an isolated worktree, the my-review agent reviews the diff, and findings route by severity (low→issues, medium→triaged fix-list, high→collective replan, critical→own cycle). For single tasks not worth slicing into an issue graph. Use for "/pipeline <issue#|task>", "pipeline this".
Deep, security-weighted review of your changes or a PR — routes the reviewer model to the change's complexity (opus by default; fable for a complex diff, on ask), then spawns the my-review agent (xhigh reasoning) on that model. Read-only, report-only. Use for "/my-review", "/my-review <PR#>".
Classify one task or issue into a complexity tier — trivial, standard, or complex — and emit that tier plus a rationale; consumers resolve the tier's {model, effort} roster via the plugin's resolve-tier.sh. Grounds the call by fanning out 1–3 Explore subagents over the touched codebase areas, then asks you to confirm or override. Use for "/classify-task <issue#|brief>", "classify this task".
Run N rounds of the autonomous issue-solving loop — pick the ready set (blockers closed, skip hitl), fan out parallel implementers in isolated git worktrees, hand the completed branches to a merger that merges in dependency order and resolves conflicts under the done-check, close finished issues, then a reviewer files blocking follow-ups. Use for "/orchestrate", "run the loop", "build the ready issues".
Check whether the plan(s)/PRD(s)/issue-slice(s) under discussion still match the decisions made in this session — a sonnet subagent reads the current session log, later decisions win, and reports drift read-only. Use for "/verify-plan", "does my plan still match what we decided?".
Capture the just-approved plan after exiting plan mode and hand it to a fresh session — write the plan to a file plus the resume pointer the workflow plugin reads, then tell me to /clear and send `go` to execute it. Use for "/handoff-plan", "hand off this plan".
