メニュー
バグや障害を体系的に調査し、エビデンスに基づいて根本原因を特定する。Use when: 「動かない」「エラーが出る」「なぜか失敗する」「原因がわからない」「デバッグしたい」「テストが落ちる」「本番で問題が起きている」「再現できない」。一般的なコードレビューにはfind-bugsを使用。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/s977043/PlanGate --skill systematic-debuggingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
アイデアや曖昧な要件を PlanGate の PBI INPUT PACKAGE に対話的に整理する。Use when: docs/working/TASK-XXXX/pbi-input.md を新規作成したい時、要件をブレストして PBI に落としたい時。
PlanGate の exec フェーズを TDD で実行する。Use when: C-3 APPROVED 後にコード実装を開始したい時、workflow-conductor 配下で実装タスクを進めたい時。
PBI INPUT PACKAGE から PlanGate の plan.md / todo.md / test-cases.md を B-1→B-2→B-3 フローで作成する。Use when: docs/working/TASK-XXXX/pbi-input.md を元に実行計画を作りたい時。
SOC 職業分類に基づく
SKILL.md を表示中
| name | systematic-debugging |
| description | バグや障害を体系的に調査し、エビデンスに基づいて根本原因を特定する。Use when: 「動かない」「エラーが出る」「なぜか失敗する」「原因がわからない」「デバッグしたい」「テストが落ちる」「本番で問題が起きている」「再現できない」。一般的なコードレビューにはfind-bugsを使用。 |
推測ではなくエビデンスに基づいて根本原因を特定する体系的デバッグプロセス。
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
原因を特定せずに修正を試みることを禁止する。3回修正に失敗したらアーキテクチャの問題として人間にエスカレーションする。
| こう思ったら | 現実 |
|---|---|
| 「原因は多分これだから先に直す」 | 推測で修正するな。まず再現・証拠を取れ |
| 「3回直しても失敗したがもう1回試す」 | 3回失敗はアーキテクチャの問題。人間にエスカレーション |
| 「ログを見れば分かる」 | ログは症状。根本原因は別のレイヤーにある可能性を疑え |
核心原則: 仮説を立てる前に事実を集める。修正する前に原因を理解する。
まず事実を集める。推測しない。
記録する項目:
□ 何が起きているか（エラーメッセージ、スタックトレース）
□ 何が期待されていたか
□ いつから発生しているか（直近の変更との関連）
□ 再現条件（常に再現？特定条件？間欠的？）
□ 影響範囲（1ファイル？複数？全体？）
調査コマンド例:
# 直近の変更を確認
git log --oneline -10
git diff HEAD~5
# テスト失敗の詳細
# プロジェクト固有のテストコマンドを使用
症状から考えられる原因を列挙する。この時点では検証しない。
| # | 仮説 | 確信度 | 検証コスト |
|---|------|--------|----------|
| 1 | {仮説A} | 高/中/低 | 小/中/大 |
| 2 | {仮説B} | 高/中/低 | 小/中/大 |
| 3 | {仮説C} | 高/中/低 | 小/中/大 |
優先順位: 確信度が高く検証コストが低い仮説から検証する。
各仮説を1つずつ検証する。複数同時に検証しない。
検証の記録:
□ 検証した仮説: {仮説名}
□ 検証方法: {何をしたか}
□ 結果: 支持 / 棄却 / 不確定
□ 根拠: {具体的なエビデンス}
検証テクニック:
根本原因が判明したら:
修正だけでなく、同種のバグの再発を防ぐ:
□ テストが追加されたか（同じバグが再発したら検出できるか）
□ 根本原因は構造的か（他の箇所にも同じ問題が潜んでいないか）
□ ドキュメントの更新が必要か
status.mdに記録する