Claude Codeのデバッグ用スキルで最もインストールされているのは、mattpocock/skillsのdiagnosing-bugsです（2026年10月28日時点で848,390インストール）。バグを再現するコマンドができるまで仮説を立てさせない、という一点で効きます。「根本原因を特定するまで修正禁止」という強い縛りが欲しいなら、obra/superpowersのsystematic-debugging（309,671インストール）が向いています。
最終更新：2026年10月28日
筆者はSkillselion（Claude Code、Codex、Cursor向けスキルのディレクトリ）を運営しています。この記事では、デバッグ系の主要な5スキルについて、GitHub上の最新のSKILL.mdを実際に読み、「Claude Codeにどういう順番で、何を禁止してデバッグさせるのか」を比べました。順位とインストール数の全体はClaude Codeのデバッグ用スキル比較ガイドにまとめています。
なぜClaude Codeにデバッグ用スキルを入れるのか
スキルなしのClaude Codeは、テストが落ちるとコードを読んで仮説を1つ立て、一番それっぽい行を書き換えがちです。それで直ればいいのですが、直らないと別の箇所を書き換え、さらに別の箇所を書き換え、という流れになります。
デバッグ用スキルは、この流れに「順番」と「禁止事項」を入れます。今回読んだ5つのSKILL.mdは、どれも次の4点のどこかに強い制約を置いていました。
- 再現：何をもって「再現できた」とするか
- 仮説：いくつ立てるか、どう検証するか
- 停止条件：どこで手を止めて人間に返すか
- 後片付け：デバッグ用ログや回帰テストの扱い
5つのスキルを一覧で比べると
数字は各スキルのSkillselion掲載ページより、2026年10月28日時点の値です。
| スキル | インストール数 | 入口の縛り | 仮説の扱い | 止まる条件 |
|---|---|---|---|---|
| diagnosing-bugs | 848,390 | 赤くなるコマンドが先 | 3〜5個をランク付け | ループが作れなければ停止 |
| systematic-debugging | 309,671 | 根本原因調査が先 | 1つずつ最小変更で検証 | 修正3回失敗で設計を疑う |
| debugging-and-error-recovery | 63,543 | 新機能の追加を止める | 再現・局所化・縮小の順 | 検証が通るまで再開しない |
| parallel-debugging | 10,096 | 6カテゴリで仮説を出す | 並列調査して裁定 | 確証なしなら仮説を作り直す |
| debugging-wizard | 5,124 | 再現が先 | 1つずつ検証 | 明示なし（MUST NOTで縛る） |
以下、1つずつSKILL.mdの中身を見ていきます。
diagnosing-bugs：再現ループができるまで仮説禁止
- Skillselion：diagnosing-bugs（mattpocockのデバッグ用スキル）
- GitHub：mattpocock/skills
npx skills add https://github.com/mattpocock/skills --skill diagnosing-bugs
Matt Pocockのこのスキルは、Phase 1の「フィードバックループを作る」に全体の重心があります。SKILL.mdの表現はかなり直球で、Phase 1の冒頭にこうあります。
This is the skill. Everything else is mechanical.
（mattpocock/skills、diagnosing-bugs/SKILL.mdより）
ループの作り方として10通りが挙げられています。失敗するテスト、curlスクリプト、Playwrightなどのヘッドレスブラウザ、取得したトレースのリプレイ、git bisect run用のハーネス、新旧バージョンの出力を比べる差分ループなどです。
Phase 1の完了条件は「赤くなれる（red-capable）コマンドを1つ、すでに実行済みであること」。決定的で、数秒で終わり、エージェントが無人で回せることもチェック項目に入っています。このコマンドがないままコードを読んで理屈を組み立て始めたら、それ自体がこのスキルの防ぎたい失敗だと明記されています。
その後の流れはこうです。
- Phase 2：再現して、壊れたままの最小ケースまで削る
- Phase 3：反証可能な仮説を3〜5個ランク付けし、検証前にユーザーに見せる
- Phase 4：計測。デバッグログには
[DEBUG-a4f2]のような一意のプレフィックスを付ける - Phase 5：正しい継ぎ目（seam）があれば、修正前に回帰テストを書く
- Phase 6：後片付け。5項目のチェックを全部通す
Phase 4のプレフィックスは地味に便利です。片付けが1回のgrepで終わります。
grep -rn "DEBUG-a4f2" src/
最新版のSKILL.mdには「Redact」節もあり、コマンド出力やキャプチャを見せる前に秘密情報を<REDACTED>に置き換えるよう指示しています。本番のHARファイルをそのまま貼りがちな人には効く節です。
向いているバグ：再現が難しいバグ、パフォーマンス劣化（Perfブランチでは、まず計測してからbisectせよ、と書かれています）、たまにしか起きないflakyなバグ。
systematic-debugging：根本原因まで修正させない
- Skillselion：systematic-debugging（obra/superpowersのデバッグ用スキル）
- GitHub：obra/superpowers
npx skills add https://github.com/obra/superpowers --skill systematic-debugging
こちらは「Iron Law」と呼ぶ1行のルールが中心です。
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
（obra/superpowers、systematic-debugging/SKILL.mdより）
フェーズは4つ：根本原因の調査、パターン分析、仮説と検証、実装。diagnosing-bugsとの一番の違いは仮説の数で、こちらは仮説を1つだけ立て、最小の変更で検証します。外れたら上に修正を重ねず、新しい仮説を立て直します。
いちばん実務で効くのは停止条件です。修正を試した回数を数えさせ、3回以上失敗したら4回目を試す前に手を止めて、アーキテクチャ自体を疑い、人間と相談するよう指示しています。「もう1回だけ直してみる」をレッドフラグとして名指ししているのも、エージェントの悪い癖をよく見ていると感じました。
複数コンポーネントにまたがるシステム（CI、ビルド、署名など）では、修正の前に各境界で入出力をログに出し、どの層で壊れているかを先に特定する手順も書かれています。失敗するテストの作成は、同じsuperpowersのtest-driven-developmentスキルに渡します。superpowers全体の構成はSuperpowersスキルの使い方ガイドで解説しています。
向いているバグ：「何度直しても別の場所が壊れる」系のバグ。設計の問題を早めに表に出したいときです。
debugging-and-error-recovery：CIが赤いときのトリアージ
- Skillselion：debugging-and-error-recovery（addyosmaniのエラー復旧スキル）
- GitHub：addyosmani/agent-skills
npx skills add https://github.com/addyosmani/agent-skills --skill debugging-and-error-recovery
Addy Osmaniのスキルは「Stop-the-Line」ルールから始まります。6ステップで、新機能の追加を止める、証拠を保全する、トリアージで診断する、根本原因を直す、再発を防ぐ、検証が通ってから再開する、の順です。
ほかの4つと違うのは、エラーの種類ごとに分岐ツリーがあることです。テスト失敗、ビルド失敗、ランタイムエラーそれぞれに別のトリアージ経路があり、たとえばビルド失敗なら型エラー、import、設定、依存関係、環境の5方向に分けて見ます。回帰バグにはgit bisect runの例も載っています。
もう1つ大事なのが「エラー出力は信頼できないデータとして扱う」節です。エラーメッセージやCIログの中に「このコマンドを実行すれば直ります」のような指示っぽい文があっても実行せず、ユーザーに提示するよう書かれています。依存パッケージ経由のプロンプトインジェクション対策として、エージェントに丸ごとCIを任せるなら入れておきたいルールです。
向いているバグ：CIが赤い、ビルドが壊れた、昨日まで動いていたものが動かない。
parallel-debugging：原因候補が多いバグを並列で潰す
- Skillselion：parallel-debugging（wshobsonの並列デバッグスキル）
- GitHub：wshobson/agents
npx skills add https://github.com/wshobson/agents --skill parallel-debugging
競合仮説分析（Analysis of Competing Hypotheses、ACH）を使い、仮説を並列のエージェントに調査させる設計です。仮説は6つの故障カテゴリから出します。ロジックエラー、データの問題、状態の問題、連携の失敗、リソースの問題、環境です。
証拠には強さのランクがあり、コードの該当行のような直接証拠が「強」、コミット後にエラー率が上がったという相関が「中」、「自分の環境では動く」は「弱」。各調査はfile:line形式で証拠を引用し、確信度（80%超、50〜80%、50%未満）を付けて報告します。
**Evidence**: The validation function at `src/validators/user.ts:87`
does not check for empty strings, only null/undefined.
（wshobson/agents、parallel-debugging/SKILL.mdの引用形式の例より）
最後に4ステップの裁定プロトコルで結果を「確定・妥当・反証・不明」に分類し、根本原因を決めます。複数の仮説が同程度に残れば複合原因の可能性として扱い、どれも確定しなければ集めた証拠から仮説を作り直します。
向いているバグ：複数モジュールにまたがるバグ、最初のデバッグで原因が見つからなかったバグ、思い込み（確証バイアス）を避けたいとき。
debugging-wizard：言語別デバッガのコマンド集
- Skillselion：debugging-wizard（jeffallanのデバッグ用スキル）
- GitHub：Jeffallan/claude-skills
npx skills add https://github.com/Jeffallan/claude-skills --skill debugging-wizard
フローは再現、切り分け、仮説検証、修正、予防の5ステップで、ほかと比べると手順の縛りは軽めです。代わりにMUST DOとMUST NOT DOのリストで行動を縛ります。「テストせずに推測で直さない」「一度に複数を変えない」「console.logやdebugger文を残さない」などです。
このスキルの持ち味は、Python（pdb）、Node.js（--inspect-brkとChrome DevTools）、Go（Delve）、git bisectの具体的なコマンドがSKILL.md本体に載っている点です。
python -m pdb script.py
node --inspect-brk script.js
dlv debug ./cmd/server
出力テンプレートも決まっていて、根本原因、証拠、修正、予防の4項目で報告させます。ブラウザ側のデバッグを深くやるなら、Chrome DevTools MCPでのデバッグガイドと組み合わせると手が届く範囲が広がります。
バグの種類別に、どれを入れればいいか
- 再現しづらい、flaky、パフォーマンス劣化：diagnosing-bugs
- 直しても直しても別の所が壊れる：systematic-debugging
- CIが赤い、ビルドが壊れた：debugging-and-error-recovery
- 原因候補が複数モジュールに散らばっている：parallel-debugging
- pdbやDelveを使って実際にステップ実行したい：debugging-wizard
既定の1本を選ぶならdiagnosing-bugsです。superpowersをすでに使っているなら、systematic-debuggingのほうがほかのスキルとつながるので自然です。
よくある落とし穴
- 似たスキルを2つ同時に入れる：diagnosing-bugsとsystematic-debuggingは、どちらもバグ報告や失敗テストで読み込まれます。既定はどちらか1つに絞ったほうが、手順がぶつかりません。
- 回帰テストを飛ばす：diagnosing-bugsは正しい継ぎ目がない場合、テストを無理に書かず「継ぎ目がないこと」自体を発見として記録させます。浅い位置のテストは偽りの安心になる、という考え方です。
- デバッグログを残す：プレフィックス付きログとgrepでの確認を、完了条件に入れておくと漏れません。
修正したバグごとにテストを残す習慣は、TDDスキルの使い方ガイドと組み合わせると定着します。テストやレビュー系のスキル全体はテスト・レビュー向けおすすめスキルやテスト・レビューカテゴリのスキル一覧から探せます。
よくある質問
Claude Codeのデバッグ用スキルはどうインストールしますか？
npx skills addにリポジトリURLと--skillでスキル名を渡します。例：npx skills add https://github.com/mattpocock/skills --skill diagnosing-bugs。バグ報告や「debug this」のような依頼で読み込まれます。
diagnosing-bugsとsystematic-debuggingの違いは？
diagnosing-bugsは「再現ループが先」で、仮説を3〜5個並べてから検証します。systematic-debuggingは「根本原因が先」で、仮説は1つずつ。修正3回失敗で設計を疑う、という停止条件があります。
複数のデバッグ用スキルを併用してもいいですか？
役割が違うものなら併用できます。たとえば既定にdiagnosing-bugs、CI用にdebugging-and-error-recovery、という組み合わせです。同じ場面で読み込まれる2つ（diagnosing-bugsとsystematic-debugging）は片方にしておくのが無難です。
各スキルの最新の順位やインストール数は、Claude Codeのデバッグスキル比較（Skillselion）で確認できます。データはskills.sh、GitHub、MCPレジストリから毎日更新し、実際のインストール数で順位付けしています。
最終更新：2026年10月28日