メニュー
Systematic debugging that applies the scientific method to failures. Use when the user says "debug this", "why is this failing", "help me find the bug", or is stuck on a problem and thrashing without progress.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/tslateman/duet --skill debuggingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | debugging |
| description | Systematic debugging that applies the scientific method to failures. Use when the user says "debug this", "why is this failing", "help me find the bug", or is stuck on a problem and thrashing without progress. |
Apply the scientific method to software failures. Observe before theorizing. Form hypotheses, design experiments, narrow the cause. Refuse to jump to fixes until the cause is isolated.
Never skip from Observe to Fix. The loop exists because human intuition about bug causes is wrong more often than right.
For a hard bug, this is the skill, everything else is mechanical. Before you hypothesize, build a tight, red-capable feedback loop: one command that drives the actual bug path and goes red on this bug, green once fixed. With it, bisection, hypothesis-testing, and instrumentation all just consume it. Without it, no amount of staring at code will save you. Spend disproportionate effort here, be aggressive, be creative, refuse to give up. See references/feedback-loops.md for the ten ways to construct one, how to tighten it, and what to do with non-deterministic bugs.
Completion criterion, a loop that goes red. Do not proceed to hypotheses until you can name one command you have already run at least once (paste the invocation and its output) that is:
If you catch yourself reading code to build a theory before this command exists, stop, jumping straight to a hypothesis is the exact failure this guards against. Then minimise: shrink the repro to the smallest scenario that still goes red, cutting one element at a time, so Phase 3's hypothesis space is small and the result becomes a clean regression test.
Apply these rules in order. Most debugging failures trace to violating one of the first three.
See references/nine-rules.md for detailed application of each rule.
Before forming any hypothesis:
- What is the exact error message or unexpected behavior?
- When did it start? What changed?
- Does it reproduce consistently?
- What is the smallest reproduction case?
List every plausible cause. Rank by:
Start with the most testable, not the most likely. Fast elimination beats slow confirmation.
Each experiment should:
When the cause lives in a large change:
## Bug
[What happened vs what was expected]
## Root Cause
[The specific defect and why it produced this symptom]
## Evidence
[What experiments confirmed this, what was ruled out]
## Fix
[The change and why it addresses the root cause]
## Prevention
[What would catch this earlier next time]
Shotgun debugging, Changing multiple things at once hoping something works. You'll never know what fixed it, or if it's actually fixed.
Debugging by coincidence, "It works now" without understanding why. The bug is still there.
The usual suspects, Blaming the framework, the OS, the compiler. It's almost always your code.
Rubber ducking without listening, Explaining the problem but not hearing your own assumptions. Slow down at the part that feels obvious.
Fix and forget, Fixing the symptom without asking why the system allowed this failure in the first place.
A good diagnosis:
/testing: Test failures trigger debugging; debugging reveals missing tests/performance: Performance regressions are bugs; profiling is debugging for speed/review: Reviews catch bugs before they need debugging/improve-codebase-architecture: when the post-mortem shows the bug had no good test seam or was enabled by tangled coupling, hand off the specificsskills/FRAMEWORKS.md: Full framework indexRECIPE.md: Agent recipe for parallel decomposition (2 workers)Audit a workspace for recurring friction, pick the highest-leverage one, and build the automation that removes it. Use when the user asks "what should I automate", "what's wasting my time", "find the friction in my workflow", wants a self-improvement pass over their own tooling, or runs this on a recurring loop.
Audit whether another agent actually did what was asked, not just whether the code is good. Use to watch, audit, compare, or fix another agent's work: a Claude Code or Codex session, a transcript, a PR, a branch, a CI run, or a workflow run.
Review what agents accomplished, surface loose ends across sessions