Claude Code Plugins

Community-maintained marketplace

Feedback

eld-debug

@CAPHTECH/claude-marketplace
0
0

|

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

name eld-debug
description ELD的デバッグ手法 - 法則（Law）視点でバグを分析・修正する。 バグを「法則からの逸脱」として捉え、証拠ループで系統的に解決する。 トリガー条件: - 「ELDでデバッグして」「法則視点でバグを調査して」 - 「証拠ベースでバグ修正して」「デバッグを体系的に進めて」 - バグ修正、障害調査、根本原因分析

ELD Debug - 法則駆動デバッグ手法

バグ = 法則（Law）からの逸脱として捉え、証拠ループで系統的に解決する手法。

核心思想

観点 従来のデバッグ ELD的デバッグ
視点 「なぜ壊れた？」 「どの法則が破られた？」
証拠 ログ・スタックトレース 法則違反の論理的証明
修正 症状の除去 法則の復元
検証 「動いた」 「法則が満たされた」（L0-L4）
蓄積 バグ票 Law/Term Card + パターン

デバッグループ

Sense → Model → Predict → Change → Ground → Record
  ↑                                            ↓
  └──────────── 法則復元まで循環 ←──────────────┘

フェーズ詳細

Phase 1: Sense（症状の観測）

目的: 症状を観測し、関連する法則候補を列挙する

観測手段

種類 手段 目的
ログ・トレース 構造化ログ、分散トレース イベント・状態変化の収集
メトリクス APM、プロファイリング 性能・リソース状態
デバッガ ステップ実行、ブレークポイント 実行時状態の詳細観測
ユーザー報告 エラーレポート、再現手順 外部視点の症状
履歴・差分 git bisect、デプロイ履歴 変更との相関

成果物

症状記録:
  現象: <何が起きているか>
  再現条件: <いつ、どのような状況で発生するか>
  影響範囲: <どのユーザー/機能に影響するか>

観測した変数:
  - 変数名: <値と期待値>

法則候補:
  - Law名: <この症状に関連しそうな法則>
    カテゴリ: [Invariant | Pre | Post | Policy]

詳細は references/evidence-collection.md 参照。

Phase 2: Model（法則違反の仮説形成）

目的: 破られた法則を特定し、論理式として表現する

仮説形成プロセス

  1. 法則の明示化: 暗黙の法則を言語化
  2. 論理式化: 自然言語を論理式に変換
  3. 違反箇所の特定: どこで法則が破られているか

成果物

破られた法則:
  Law名: <名前>
  カテゴリ: [Invariant | Pre | Post | Policy]
  論理式: <∀x. P(x) → Q(x) 形式>
  自然言語: <平易な説明>

仮説:
  原因推測: <なぜ法則が破られたか>
  根拠: <仮説を支持する観測事実>
  反証可能性: <この仮説が間違っていたら何が観測されるか>

Phase 3: Predict（影響予測）

目的: 法則違反の影響範囲と、修正による副作用を予測する

予測内容

  1. 伝播範囲: 法則違反がどこまで影響しているか
  2. 副作用: 修正による意図しない変更
  3. 失敗モード: 修正がうまくいかなかった場合の兆候

成果物

影響予測:
  直接影響: <法則違反の直接的影響>
  間接影響: <伝播による二次的影響>

修正予測:
  期待効果: <修正で何が改善されるか>
  副作用リスク: <意図しない変更のリスク>

停止条件:
  - <このサインが出たら修正アプローチを見直す>

Phase 4: Change（法則復元）

目的: 最小限の変更で法則を復元する

変更原則

  1. 最小変更: 法則復元に必要な最小の変更
  2. Pure優先: 副作用のない変更を優先
  3. 可逆性確保: ロールバック可能な状態を維持

成果物

変更内容:
  ファイル: <変更対象>
  差分: <変更内容>
  意図: <なぜこの変更で法則が復元されるか>

検証ポイント:
  - <変更後に確認すべきこと>

Phase 5: Ground（証拠による検証）

目的: 法則が復元されたことを証拠で確認する

証拠の梯子（Evidence Ladder）

Level 手段 検証内容
L0 型チェック・静的解析 法則が「書ける」か
L1 ユニットテスト・Property-based test 法則が単体で成立するか
L2 統合テスト・E2Eテスト 法則が連携で成立するか
L3 失敗注入・Fuzz testing 法則が異常時も守られるか
L4 本番Telemetry・監視 法則が実運用で成立しているか

成果物

達成レベル: L[0-4]

証拠一覧:
  - 証拠種別: <テスト/ログ/メトリクス>
    内容: <何を検証したか>
    結果: <Pass/Fail>

法則復元確認:
  論理式: <検証した法則>
  検証方法: <どう検証したか>
  結果: [復元された | 部分的 | 未達成]

詳細は references/evidence-collection.md 参照。

Phase 6: Record（知識の蓄積）

目的: バグパターンと解決策を将来のために記録する

記録内容

  1. バグパターン: 法則違反のパターンとして抽象化
  2. 根本原因: なぜ法則が破られたかの分析
  3. 検出方法: このパターンを早期発見する方法
  4. 防止策: 再発を防ぐための施策

成果物

バグパターン:
  パターン名: <識別しやすい名前>
  法則違反タイプ: [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、分散トレース、メトリクス、エラーレポート

完了条件

  • 破られた法則が特定されている
  • 法則が復元されたことが証拠で確認されている（L1以上）
  • バグパターンが記録されている
  • 必要に応じてLaw/Term Cardが更新されている

使用例

例1: 在庫計算の不整合

# 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 明示的ロック

例2: API認証エラー

# 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-law-discovery - 法則発見
  • /eld-ground-check - 接地検証
  • /eld-record-collection - 知識蓄積