菜单
Debugging discipline. Use whenever diagnosing a bug, error, test failure, crash, regression, flaky behavior, or unexpected output, and especially before applying any fix. Also trigger when a previous fix attempt did not work and another attempt is about to be made.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Subagent orchestration and verification discipline. Use whenever a task has independent subtasks that could run in parallel, whenever work is substantial enough to need checking before it ships, and whenever tempted to review your own work by re-reading it. Trigger on multi-file changes, audits, migrations, reviews, and any long-running build.
Data-skepticism discipline for quantitative work. Use whenever reading data and producing a conclusion: analytics questions, metrics reports, spreadsheet analysis, SQL queries, dashboards, A/B results, forecasts, or any claim of the form "the data shows." Trigger before presenting any number or trend to a user.
Autonomy and checkpoint discipline for agentic work. Use on every task where the model works with tools over multiple steps. Trigger especially when about to ask the user a question, end a turn, propose a plan, or write phrases like "I'll now," "next I will," "want me to," "shall I," or "let me know."
Cross-run memory discipline for agents with a persistent workspace. Use at the end of any session where something non-obvious was learned (a correction from the user, a confirmed approach, a trap in the environment), and at the start of any task similar to past work. Trigger on user corrections, surprising failures, and hard-won configuration or debugging discoveries.
Scope discipline for code changes. Use whenever writing or editing code: implementing a feature, fixing a bug, or modifying existing files. Trigger especially when tempted to refactor, clean up, add error handling, add configuration options, or restructure code beyond what the task asked for.
Prose discipline for any written deliverable. Use whenever writing for a human reader: answers, explanations, reports, summaries, documentation, PR descriptions, emails, or analyses. Trigger especially when the draft is getting long, when reaching for headers and bullet points, or when compressing text with fragments and abbreviations.
| name | root-cause-first |
| description | Debugging discipline. Use whenever diagnosing a bug, error, test failure, crash, regression, flaky behavior, or unexpected output, and especially before applying any fix. Also trigger when a previous fix attempt did not work and another attempt is about to be made. |
Fix causes, not symptoms. A fix applied to an undiagnosed problem is a guess, and guesses compound: each one changes the system, making the real cause harder to see.
When a fix attempt fails, write down (in a scratch file or your working notes) before doing anything else:
Then, and only then, form the next hypothesis. The ledger exists to enforce one rule: never retry a failed approach verbatim. If you find yourself making the same edit a second time, or re-running the same command hoping for a different result, stop. That is the signal you are guessing.
After two failed fix attempts, stop fixing and restart diagnosis from scratch:
The most expensive debugging sessions are not the hard bugs. They are the easy bugs treated with a sequence of confident guesses, each of which added noise. Diagnosis feels slower than guessing and is almost always faster.
