---

name: eld description: | Evidence-Loop Development (ELD) - 証拠で回す統合開発手法。 コード観測（旧DCCA）、Law/Term規範（旧LDE）、安全な変更（旧Proprioceptive）、 知識管理（旧PCE）を統一ループで実行する。

トリガー条件:

• 「ELDで進めて」「証拠ループで実装して」
• 「コードベースを理解して」「影響範囲を分析して」（旧DCCA）
• 「Lawを定義して」「Termをカード化して」（旧LDE）
• 「安全に変更して」「証拠パックを作成して」（旧Proprioceptive）
• 「コンテキスト駆動で実装して」「PCEで進めて」（旧PCE）
• 「ELDでデバッグして」「法則視点でバグ調査して」（デバッグ）
• 新機能開発、バグ修正、リファクタリング、障害調査

---

Evidence-Loop Development (ELD)

証拠で回す統合開発手法。コードを「相互接続された意味のグラフ」として理解し、 Law/Termで規範を定め、安全な微小変更で実装し、知識を構造化して蓄積する。

核心原則

1. Epistemic Humility: 推測を事実として扱わない。unknownと言う勇気を持つ
2. Evidence First: 結論ではなく因果と証拠を中心にする
3. Grounded Laws: Lawは検証可能・観測可能でなければならない
4. Minimal Change: 最小単位で変更し、即時検証する
5. Source of Truth: 真実は常に「現在のコード」。要約をインデックスとして扱う

統一ループ

CopySense → Model → Predict → Change → Ground → Commit → Record
  ↑                                                      ↓
  └──────────────────── 循環 ←───────────────────────────┘

統一概念

Evidence Pack（証拠パック）

変更の正当性を証明する一式の証拠。PRの中心。

Epistemic Status（認識論的状態）

• verified: コードまたはテストで確認済み
• inferred: 構造や慣習から推論
• unknown: 確認不能/要調査

Evidence Ladder（証拠の梯子）

Issue Contract（ローカル契約）

• 目的（Goal）
• 不変条件（Invariants）
• 物差し（Acceptance Criteria）
• 停止条件（Stop Conditions）

Law/Term（グローバル法則）

• Law: ビジネス上の「守るべき条件」（Invariant/Pre/Post/Policy）
• Term: ドメインの語彙（Entity/Value/Context/Boundary）
• Link Map: Law ↔ Term の相互参照。孤立禁止

詳細は 00-glossary.md を参照。

開発フロー

Phase 1: Issue（受付）

Copy成果物:
  - Issue Contract: 目的/不変条件/物差し/停止条件
  - 現状証拠: Senseフェーズの観測結果
  - Term/Law候補: Modelフェーズの初期出力

実行内容: 0. 要件明確化 (新機能開発時):

• /eld-sense-requirements-brainstorming で要件の曖昧さを対話的に解消
• Law/Term観点、境界条件、失敗モードから体系的に質問
• Issue Contract 下書き生成

1. pce.memory.activate で関連知識を活性化
2. 目的に応じたツールでコード調査（10-sense.md 参照）
   • 特定キーワード → Grep
   • 定義・参照追跡 → LSP / serena
   • シンボル検索 → serena（利用可能時）
   • 意味的関連探索 → kiri context_bundle
3. Issue Contractを作成（issue-template.md使用）
4. Term/Law候補を列挙

使用スキル: /eld-sense-requirements-brainstorming (新機能時), /eld-sense-activation, /eld-model-law-discovery

Phase 2: Design（設計）

Copy成果物:
  - Law/Term Cards: 相互参照あり、孤立なし
  - Grounding Plan: 必要テスト/Telemetry（Evidence Ladder対応）
  - Change Plan: 微小変更列＋各ステップのチェック

実行内容:

1. Law Card化（Scope/例外/違反時動作）
2. Term Card化（意味/境界/観測写像）
3. Link Map更新（孤立チェック）
4. 影響予測と段階化計画
5. Grounding Plan策定（/test-design-auditでテスト設計）

使用スキル: /eld-model-law-card, /eld-model-term-card, /test-design-audit

Phase 3: Implementation（実装ループ）

各ステップを同じ型で回す:

Copy1. Sense   → 触るシンボル/境界/設定の身体図更新
2. Predict → 期待される因果と失敗モード
           → High/Criticalリスク時はworktree提案
3. Change  → 最小単位で変更、Pure/IO分離を維持
           → worktree隔離環境で実験（高リスク時）
4. Ground  → テスト/Telemetryで観測写像を満たす
           → TDD強制（RED-GREEN-REFACTOR）でL1達成
5. Commit  → 検証通過後にコミット（詳細: 40-change.md）
6. Record  → Context Delta記録

高リスク変更の隔離:

• リスクレベルがHigh/Criticalの場合、worktreeで隔離環境作成
• 実験成功後、Cherry-pick/Rebase/Mergeでmainに統合
• 失敗時は即座にworktree削除で元に戻る

TDD強制:

• S0/S1 Lawは必ずL1（ユニットテスト）達成が必須
• RED（失敗テスト）→ GREEN（最小実装）→ REFACTOR（品質改善）サイクル
• テストなし実装を許さず、コミット前にEvidence L1確認

使用スキル: /eld-change-worktree, /eld-ground-tdd-enforcer, /eld-predict-impact, /eld-record-collection

停止条件チェック:

• 予測と現実の継続的乖離
• 観測不能な変更の増加
• ロールバック線の崩壊

Phase 4: Review（レビュー）

Copy証拠パック中心:
  - 因果と証拠の整合
  - Law/Term孤立チェック
  - 影響範囲のグラフ証拠
  - Evidence Ladder達成レベル

使用スキル: /eld-ground-check

PR作成: pr-template.md 使用

Phase 5: Ops（運用）

• Telemetryで Law違反を監視
• Context Deltaを回収→構造化
• 物差しの再点検
• pce-memoryへのフィードバック

知識ストア

pce-memory 3層構造

品質優先原則（Superpowers統合）

核心原則

1. Epistemic Humility: 推測を事実として扱わない。unknownと言う勇気を持つ
2. Evidence First: 結論ではなく因果と証拠を中心にする
3. Minimal Change: 最小単位で変更し、即時検証する
4. Grounded Laws: Lawは検証可能・観測可能でなければならない
5. Source of Truth: 真実は常に現在のコード。要約はインデックス

「速さより質」の実践

• 要件の曖昧さによる手戻りを根本から排除
• テストなし実装を許さない
• 観測不能な変更を防ぐ

完了条件・停止条件の詳細は次セクション参照。

完了条件と停止条件

完了条件

• Issue Contractの物差しが満たされている
• Law/Termが接地している（Evidence Ladder L1以上）
• Evidence Packが揃っている
• Link Mapに孤立がない

停止条件（発生時は追加計測/スコープ縮小）

• 予測と現実の継続的乖離（想定外のテスト失敗3回以上）
• 観測不能な変更の増加（物差しで検証できない変更）
• ロールバック線の崩壊（戻せない変更の発生）

リファレンス

概念定義

• 00-glossary.md - 統一語彙

フェーズ詳細

• 10-sense.md - 感知フェーズ（旧DCCA）
• 20-model.md - モデル化フェーズ（旧LDE Law/Term発見）
• 30-predict.md - 予測フェーズ（旧Proprioceptive）
• 40-change.md - 変更フェーズ
• 50-ground.md - 接地フェーズ
• 60-record.md - 記録フェーズ（旧PCE）

テンプレート

• issue-template.md - Issue Contract雛形
• pr-template.md - PR & Evidence Pack雛形
• law-term-card.md - Law/Term Card雛形

使用例

CopyUser: ユーザー認証機能をELDで実装して

Claude:
## ELD Phase 1: Issue

### Issue Contract
- 目的: JWTベースの認証機能実装
- 不変条件: 既存APIとの後方互換性
- 物差し: 認証テスト通過 + レスポンス<200ms
- 停止条件: セキュリティ脆弱性発見時

### 現状証拠（Sense）
[verified]
- 既存認証: src/auth/legacy.ts:23-45（Basic認証）
- 関連モジュール: src/middleware/auth.ts

[unknown]
- 外部認証プロバイダとの連携状況

### Term/Law候補（Model）
- TERM-jwt-token: JWT形式のアクセストークン（S1）
- TERM-refresh-token: リフレッシュトークン（S1）
- LAW-token-expiry: アクセストークンは1時間で失効（S0）
- LAW-refresh-validity: リフレッシュトークンは7日間有効（S1）

Phase 2: Designに進みますか？

デバッグへの適用

ELDの統一ループはデバッグにも適用できる。バグを「法則（Law）からの逸脱」として捉え、 証拠ループで系統的に解決する。

デバッグループ

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

ELD的デバッグの特徴

詳細は /eld-debug スキルを参照。

ユーティリティスキル

ELDループ内で使用する補助スキル:

Sense（感知）

Model（モデル化）

Change/Commit（変更・コミット）

Ground（接地）

Record（記録）

Debug（デバッグ）