# Eld

> Evidence-Loop Development (ELD) v5をリスク適応型で実行する統合スキル。観測・仮説・決定・Law・Evidenceを分離し、explore/P0/P1/P2経路を選んで実装・検証・記録する。「ELDで進めて」「証拠ベースで安全に変更して」「ELDでデバッグして」など、ELD全工程を明示的に依頼された時に使用する。単なるコード調査、一般的なPRレビュー、個別のLaw/Term作成には使用しない。

- Skill: `caphtech/eld` (Agent Skill, multi-file: 14 files)
- Install (CLI): `npx skillmds@latest add caphtech/eld`
- Raw SKILL.md: https://api.skillmd.com/api/skills/caphtech/eld/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: CAPHTECH (https://skillmd.com/u/caphtech)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/caphtech/eld

---


# Evidence-Loop Development v5

ELDを、すべての変更へ同じ儀式を課すSDLCではなく、リスクと不確実性に応じて使う開発オーバーレイとして実行する。

## 非交渉ルール

1. 現在の実装を規範へ自動昇格しない。
2. `Observation`、`Hypothesis`、`Decision`、`Law`、`Evidence`、`Outcome`を混同しない。
3. Evidenceを単一スコアや梯子で順位付けしない。
4. 正本を一つにし、Catalog・Link Map・集計表は派生物として生成する。
5. 変更リスクではなくファイル数だけで経路を決めない。
6. 失敗・不一致・不明を削除せず、`inconclusive`または未解決として残す。
7. ユーザー価値と運用成果を、証拠成果物の充足より上位に置く。

正準概念と成果物の関係を判断する時は [references/00-glossary.md](references/00-glossary.md) を読む。

## 経路を選択する

最初に目的、可逆性、影響範囲、不確実性、観測可能性、規制・セキュリティ影響を確認する。

| Route | 適用 | 必須成果物 |
|---|---|---|
| `explore` | 解法・要件・原因が未確定 | Observation、反証可能なHypothesis、実験結果、次の判断 |
| `P0` | 局所的・可逆・既存契約を変えない | 変更要約、対象に合う検証結果 |
| `P1` | 振る舞い変更、複数境界、限定的な利用者影響 | Issue Contract、Impact、Evidence Profile、ロールバック |
| `P2` | 公開契約、永続データ、認証認可、課金、規制、不可逆変更 | P1一式、承認済みDecision/Law、段階化、独立レビュー、運用観測計画 |

複数条件に該当する場合は高い経路を選ぶ。不確実性が高く分類できない場合は先に`explore`へ進む。詳細判定は [references/30-predict.md](references/30-predict.md) を読む。

## 実行フロー

### 1. Sense

現在の事実を出典付きで観測する。観測できない事項はHypothesisまたはUnknownとして分離する。調査手順が必要な場合は [references/10-sense.md](references/10-sense.md) を読む。

### 2. Route

`explore/P0/P1/P2`を判定し、理由と不足情報を示す。経路は新しい証拠で昇降格できる。降格時は、可逆性と影響限定の証拠を示す。

### 3. Spec when needed

耐久性のある語彙または規範を変更する場合だけSpecを作る。

- ObservationからLawを直接作らない。
- LawはDecisionの承認結果として作る。
- `proposed → accepted → deprecated`のライフサイクルを使う。
- P0や一時的実験にLaw/Term作成を強制しない。

カード形式と承認規則は [references/20-spec.md](references/20-spec.md) と [references/law-term-card.md](references/law-term-card.md) を読む。

### 4. Change

経路に必要な最小単位で変更する。コミット粒度は変更の意味とロールバック境界で決め、時間やファイル数で固定しない。実装原則は [references/40-change.md](references/40-change.md) を読む。

### 5. Ground

各重要主張に必要なEvidence Profileを埋める。

```yaml
evidence_profile:
  claim: <検証する主張>
  kind: static | test | integration | runtime | review | user-outcome
  relevance: direct | indirect
  independence: self | independent
  result: pass | fail | inconclusive
  freshness: current | stale
  source: <再現可能な参照>
```

本番観測を自動的に最上位と扱わない。必要証拠と判定方法は [references/50-ground.md](references/50-ground.md) を読む。

### 6. Record selectively

将来の判断を変える耐久性のある差分だけ記録する。作業ログや自明な事実を永続化しない。`CLAUDE.md`、ADR、Catalogなど共有正本への書き込みは、ユーザーの依頼または既存プロジェクト規約を確認してから行う。記録規則は [references/60-record.md](references/60-record.md) を読む。

### 7. Outcome

技術的適合だけでなく、Issue Contractの利用者・運用成果を確認する。未観測なら成功と断定せず、観測予定とOwnerを残す。

## 完了条件

- 選択経路の必須成果物が揃っている。
- Acceptance Criteriaを直接扱うEvidenceがある、または未観測と明示されている。
- `fail`と`inconclusive`が未解決事項として残っている。
- P1/P2はロールバックまたは不可逆性の承認がある。
- P2は独立レビューと運用観測計画がある。
- 永続成果物を作った場合、Ownerと状態が明確である。

## 停止条件

- 権限者不明のままLawを`accepted`にしようとしている。
- 不可逆変更に復旧方針または明示的なリスク受容がない。
- セキュリティ・課金・データ損失の重大懸念が未解決である。
- Evidenceが対象主張を直接扱っていないのに合格扱いしようとしている。
- Outcome未観測を成功として記録しようとしている。

停止時は、停止理由、確認済み事実、未確定事項、安全に進める最小アクションを返す。

## 条件付きリファレンス

- Issue Contractを作る時: [references/issue-template.md](references/issue-template.md)
- PR/Evidence Packを作る時: [references/pr-template.md](references/pr-template.md)
- Predict結果を定型化する時: [references/predict-light-template.md](references/predict-light-template.md)
- Claimを永続化・検証する時: [references/claim-schema.md](references/claim-schema.md)
- レビュー方式を選ぶ時: [references/review-hybrid-guide.md](references/review-hybrid-guide.md)