Stats
Actions
Tags
From eld-plugin
ELD的デバッグ手法 - 法則（Law）視点でバグを分析・修正する。 バグを「法則からの逸脱」として捉え、証拠ループで系統的に解決する。 トリガー条件: - 「ELDでデバッグして」「法則視点でバグを調査して」 - 「証拠ベースでバグ修正して」「デバッグを体系的に進めて」 - バグ修正、障害調査、根本原因分析
How this skill is triggered — by the user, by Claude, or both
Slash command
/eld-plugin:eld-debugThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**バグ = 法則（Law）からの逸脱**として捉え、証拠ループで系統的に解決する手法。
バグ = 法則（Law）からの逸脱として捉え、証拠ループで系統的に解決する手法。
| 観点 | 従来のデバッグ | ELD的デバッグ |
|---|---|---|
| 視点 | 「なぜ壊れた？」 | 「どの法則が破られた？」 |
| 証拠 | ログ・スタックトレース | 法則違反の論理的証明 |
| 修正 | 症状の除去 | 法則の復元 |
| 検証 | 「動いた」 | 「法則が満たされた」（L0-L4） |
| 蓄積 | バグ票 | Law/Term Card + パターン |
Sense → Model → Predict → Change → Ground → Record
↑ ↓
└──────────── 法則復元まで循環 ←──────────────┘
目的: 症状を観測し、関連する法則候補を列挙する
| 種類 | 手段 | 目的 |
|---|---|---|
| ログ・トレース | 構造化ログ、分散トレース | イベント・状態変化の収集 |
| メトリクス | APM、プロファイリング | 性能・リソース状態 |
| デバッガ | ステップ実行、ブレークポイント | 実行時状態の詳細観測 |
| ユーザー報告 | エラーレポート、再現手順 | 外部視点の症状 |
| 履歴・差分 | git bisect、デプロイ履歴 | 変更との相関 |
症状記録:
現象: <何が起きているか>
再現条件: <いつ、どのような状況で発生するか>
影響範囲: <どのユーザー/機能に影響するか>
観測した変数:
- 変数名: <値と期待値>
法則候補:
- Law名: <この症状に関連しそうな法則>
カテゴリ: [Invariant | Pre | Post | Policy]
詳細は references/evidence-collection.md 参照。
目的: 破られた法則を特定し、論理式として表現する
破られた法則:
Law名: <名前>
カテゴリ: [Invariant | Pre | Post | Policy]
論理式: <∀x. P(x) → Q(x) 形式>
自然言語: <平易な説明>
仮説:
原因推測: <なぜ法則が破られたか>
根拠: <仮説を支持する観測事実>
反証可能性: <この仮説が間違っていたら何が観測されるか>
目的: 法則違反の影響範囲と、修正による副作用を予測する
影響予測:
直接影響: <法則違反の直接的影響>
間接影響: <伝播による二次的影響>
修正予測:
期待効果: <修正で何が改善されるか>
副作用リスク: <意図しない変更のリスク>
停止条件:
- <このサインが出たら修正アプローチを見直す>
目的: 最小限の変更で法則を復元する
変更内容:
ファイル: <変更対象>
差分: <変更内容>
意図: <なぜこの変更で法則が復元されるか>
検証ポイント:
- <変更後に確認すべきこと>
目的: 法則が復元されたことを証拠で確認する
| Level | 手段 | 検証内容 |
|---|---|---|
| L0 | 型チェック・静的解析 | 法則が「書ける」か |
| L1 | ユニットテスト・Property-based test | 法則が単体で成立するか |
| L2 | 統合テスト・E2Eテスト | 法則が連携で成立するか |
| L3 | 失敗注入・Fuzz testing | 法則が異常時も守られるか |
| L4 | 本番Telemetry・監視 | 法則が実運用で成立しているか |
達成レベル: L[0-4]
証拠一覧:
- 証拠種別: <テスト/ログ/メトリクス>
内容: <何を検証したか>
結果: <Pass/Fail>
法則復元確認:
論理式: <検証した法則>
検証方法: <どう検証したか>
結果: [復元された | 部分的 | 未達成]
詳細は references/evidence-collection.md 参照。
目的: バグパターンと解決策を将来のために記録する
バグパターン:
パターン名: <識別しやすい名前>
法則違反タイプ: [Invariant | Pre | Post | Policy]
症状: <典型的な現れ方>
根本原因:
原因カテゴリ: [設計/実装/環境/運用]
詳細: <なぜ発生したか>
検出・防止:
早期検出方法: <テスト/監視/レビュー>
防止策: <設計/プロセス/ツール>
関連Law/Term:
- Law: <更新/新規作成したLaw>
- Term: <関連するTerm>
詳細は references/evidence-collection.md 参照。
| 軸 | 区分 |
|---|---|
| タイミング | 静的（実行前）/ 動的（実行中）/ 事後（実行後） |
| レイヤー | コード / ランタイム / インフラ / ユーザー |
| 目的 | 観測（発見）/ 検証（確認） |
| Level | 主な収集方法 |
|---|---|
| L0 | 型チェック、Lint、静的解析、形式検証 |
| L1 | ユニットテスト、Property-based test、アサーション |
| L2 | 統合テスト、E2Eテスト、契約テスト |
| L3 | Chaos testing、Fuzz testing、サニタイザ |
| L4 | APM、分散トレース、メトリクス、エラーレポート |
unknownと言う勇気を持つ# Sense
症状: 在庫数が負の値になることがある
観測: stock = -5, available = 10, reserved = 15
法則候補: 保存則（stock = available + reserved）
# Model
破られた法則:
Law名: 在庫保存則
論理式: ∀t. stock(t) = available(t) + reserved(t)
仮説: 並行処理で予約済みが二重加算
# Predict
影響: 決済処理、在庫表示、レポート
副作用リスク: ロック導入による性能劣化
# Change
変更: トランザクション境界の修正
意図: 予約操作を原子的に実行
# Ground
L1: Property-based testで保存則を検証
L2: 並行予約の統合テスト
L3: タイムアウト時の保存則維持テスト
# Record
パターン: 並行処理での二重計上
防止策: STM使用 or 明示的ロック
# Sense
症状: 特定ユーザーだけ認証が通らない
観測: token有効期限内、権限正常
法則候補: 認証トークン検証法則
# Model
破られた法則:
Law名: トークン有効性法則
論理式: valid(token) ∧ ¬expired(token) → authenticated
仮説: タイムゾーン差異で有効期限判定が不正
# Ground
L1: タイムゾーン跨ぎのユニットテスト
L2: 実際のトークンでの統合テスト
# Record
パターン: タイムゾーン依存のバグ
検出方法: 異なるTZでのテスト追加
references/evidence-collection.md - 証拠収集方法の体系references/debug-phases.md - 各フェーズの詳細手順/eld-sense-activation - Senseフェーズの詳細/eld-model - 法則発見・Card作成/eld-ground-verify - 接地検証/eld-record - 知識蓄積以下が発生したら即座に停止し、追加計測またはスコープ縮小：
npx claudepluginhub caphtech/claude-marketplace --plugin eld-pluginSystematic debugging methodology for finding and fixing bugs through root cause analysis. Covers reproduce-investigate-hypothesize-fix-prevent workflow, evidence-based diagnosis, and bug category strategies.
Enforces systematic root cause investigation for bugs, test failures, and unexpected behavior through four phases: investigation, pattern analysis, hypothesis testing, and implementation.
Provides a structured root-cause debugging workflow for any bug, test failure, or unexpected behavior. Run before proposing fixes to avoid random or symptom-level patches.