systematic-debugging
修正前に体系的なデバッグで根本原因を特定する
こちらからも入手できます: Cygnusfear,Cycleaddict,Doyajin174,DMJGilbert,Asmayaseen,DYAI2025,davila7,CodingCossack,obra,ChrisWiles
行き当たりばったりの修正は時間の無駄であり、新たなバグを生み出します。このスキルは、ソリューションの実装前に根本原因を特定する 4 段階のデバッグフレームワークを提供し、症状に基づく修正への無駄な労力を防ぎます。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「systematic-debugging」を使用しています。 誤ったディレクトリでの git init エラーでテストが失敗
期待される結果:
- フェーズ 1 - 根本原因調査：
- 1. エラーは git init が /tmp ではなく /source/code で実行されたことを示す
- 2. 逆方向に追跡：git init <- WorktreeManager <- Session.create <- テスト
- 3. 発見：projectDir が空文字列で、process.cwd() に解決された
- 4. 根本原因：テストが beforeEach で初期化される前に context.tempDir にアクセスした
- 根本原因を特定：変数の初期化順序の問題
「systematic-debugging」を使用しています。 ツール結果を時々見逃す不安定なテスト
期待される結果:
- 診断：テストが条件チェックではなく任意の setTimeout 待機を使用
- 解決策：タイムアウトを条件ベースの待機に置き換え
- 変更前：await new Promise(r => setTimeout(r, 300))
- 変更後：await waitForEventCount(threadManager, id, 'TOOL_RESULT', 2)
- 結果：60% の合格率が 100% に改善
セキュリティ監査
低リスクStatic analyzer flagged 126 patterns but 125 are false positives from markdown documentation (backticks are code formatting, not shell execution). One legitimate shell script (find-polluter.sh) uses npm test for test debugging - acceptable for a debugging skill. No cryptographic code exists despite scanner claims. Skill teaches debugging methodology safely.
低リスクの問題 (1)
リスク要因
⚙️ 外部コマンド (1)
品質スコア
作れるもの
テスト失敗の調査
テストが間欠的または予期せず失敗する場合、このスキルを使用して、簡単な修正を適用するのではなく、失敗を体系的に追跡して根本原因まで遡ります。
本番環境バグの解決
本番環境でバグが発生した場合、新たな問題を生む可能性のある修正をデプロイする前に、4 段階のプロセスに従って根本原因を理解します。
多コンポーネントデバッグ
複数の層を持つ複雑なシステムをデバッグする場合、防御多重化の診断を使用して、どのコンポーネントが失敗しているかを正確に特定します。
これらのプロンプトを試す
このエラーが発生しています：[エラーを貼り付け]。すぐに修正したいですが、まずは調査すべきだと理解しています。修正を提案する前に根本原因を理解するために、体系的デバッグのフェーズ 1 に従うのを手伝ってください。
このテストは間欠的に失敗します：[テストを貼り付け]。通ることもあれば、失敗することもあります。診断用インストルメンテーションの追加方法を含め、不安定さの原因を特定するために体系的デバッグをガイドしてください。
[N] 回の修正を試みましたが、どれも機能しませんでした。各修正が新たな問題を明らかにしました。さらに修正を試みる前に、アーキテクチャの問題があるかどうかを疑うのを手伝ってください。フェーズ 1 から再分析するのをガイドしてください。
ベストプラクティス
- 修正を提案する前に必ずフェーズ 1 の調査を完了する - 根本原因を理解する方が、行き当たりばったりの修正で右往左往するよりも速い
- エラーが表示される場所だけでなく、元のトリガーを特定するために呼び出しスタックを逆方向にトレースする
- 3 回の修正失敗後、症状修正を続けるのではなく、アーキテクチャを疑うこと
回避
- 根本原因調査を完了する前に修正を提案する - これは原因ではなく症状を治療することになる
- 一度に複数の変更を行う - 何が機能したかを特定できず、新たなバグを導入する可能性がある
- 失敗するテストの作成をスキップする - テストされない修正は定着せず、回帰に気づかない