# Uncertainty Resolution

> 不確実性を発見・台帳化し、優先順位付け・観測タスク化を経て、検証結果をDecision proposalと必要に応じたproposed Lawへ整理する。使用タイミング: 不確実性/曖昧さ/未知/仮説/検証/調査/リスク/前提/優先順位/観測/意思決定の話題が出たとき。観測結果をaccepted Lawへ自動昇格しない。

- Skill: `caphtech/uncertainty-resolution` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add caphtech/uncertainty-resolution`
- Raw SKILL.md: https://api.skillmd.com/api/skills/caphtech/uncertainty-resolution/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/uncertainty-resolution

---


# Uncertainty Resolution

不確実性の発見からDecision proposalまでを一貫して扱う。

## $ARGUMENTS

| 値 | 実行範囲 |
|---|---|
| `register-only` | Phase 1-2のみ（台帳作成+観測タスク化） |
| `full`（デフォルト） | Phase 1-3すべて（Decision proposalまで） |

引数なしは `full` として扱う。

## Phase 1: 不確実性の発見・台帳化

### Step 1: 意思決定のフレーミング
1〜3行で明確化する:
- 決めたいこと（Decision）
- 期限（When）
- 失敗時の損失（Stakes）
- 制約（Constraints）

### Step 2: 不確実性の列挙
`assets/uncertainty-register.md` テンプレートを使い、まず10個まで項目化する。
足りない場合のみ増やす。抜け漏れチェックには [references/triage-questions.md](references/triage-questions.md) を使う（不確実性の洗い出し観点リスト）。

各項目を「〜は本当に成り立つか？」の疑問文に整える。
既に観測で答えが出ているものは事実として別枠へ移す。

### Step 3: 優先順位付け
各項目に1〜5でスコアを付ける。詳細基準は [references/scoring.md](references/scoring.md) を参照（Impact/Evidence/Urgency/Effortの各レベル定義）。

```
Priority = Impact x (6 - Evidence) x Urgency / Effort
```

上位N（通常3〜5）を選ぶ。

## Phase 2: 観測タスク化

### Step 4: 観測タスクへ変換
上位Nについて `assets/observation-task.md` テンプレートを使い、各タスクに必ず含める:
- Hypothesis（仮説）
- Method（現物/証拠/知識）
- Timebox（上限時間）
- Decision rule（採用/撤回の条件）
- Evidence artifact（ログ/スクショ/計測/テスト結果など）

観測方法の選択には [references/observation-methods.md](references/observation-methods.md) を参照（現物観測・証拠観測・知識観測の使い分け）。

### Step 5: 計画の検証と実行（高リスク時に推奨）
破壊的・大量の作業に繋がる場合:
1. `uncertainty_plan.json` を出力
2. `python scripts/validate_uncertainty_plan.py uncertainty_plan.json` で検証
3. エラーがあれば修正して再検証
4. OKなら実行に進む

### Step 6: クローズ
各項目を Validated / Rejected / Accepted に更新し、Evidenceを必ず残す。
意思決定が絡む場合は `assets/decision-record.md` テンプレートを使う。

`$ARGUMENTS` が `register-only` の場合はここで終了。

## Phase 3: Decision proposal（ELD連携）

検証結果を、規範として採用するか判断できるDecision proposalへ変換する。観測済みであることは、Lawとして承認済みであることを意味しない。

### Step 7: 耐久的な規範候補の選定

Phase 2でValidatedになった仮説から、以下の全条件を満たすものだけをDecision候補にする:
- 観測タスクで検証済み
- 複数回/セッションで再確認済み
- ビジネス影響度 >= 3
- 検証・観測手段が定義可能
- 証拠が記録されている

### Step 8: Decision proposal生成

候補ごとに選択肢、採用理由、反証Evidence、影響、Owner、Authorityを整理する。耐久的な制約が必要な場合だけ`proposed` Law Card案を添える。
テンプレートと変換規則は [references/law-promotion.md](references/law-promotion.md) を参照する。

### Step 9: レビュー・承認

1. AuthorityがDecision proposalをレビューする
2. 未承認ならHypothesisまたはproposed Lawとして保持する
3. 明示承認がある場合だけ`/eld-spec-card law`でaccepted Lawを作成する
4. CatalogとLink MapはCardから派生生成する

## Operating Principles
- 1項目 = 1つの不確実性（疑問文）に分解する
- スコアは「観測リソース配分」のために使う。絶対視しない
- 観測タスクは「結果が出たら意思決定が進む」形にする
- 時間がない場合は仮定を置いてRegisterに"仮定"として記録する
- Decision保留の仮説には追加の観測タスクを提案する

## Assets
- `assets/uncertainty-register.md` - 台帳テンプレート
- `assets/uncertainty-card.md` - 個別項目の詳細テンプレート
- `assets/observation-task.md` - 観測タスクテンプレート
- `assets/decision-record.md` - 意思決定記録テンプレート

## Example

より詳しい例は [references/example.md](references/example.md) を参照（MVPでオフライン機能を入れるかの意思決定例）。

入力: 「この機能、ユーザーが本当に必要か分からない。技術的にも不安。どう進める？」

出力:
1. Decision/Constraints のフレーミング
2. Uncertainty Register（10件以内）
3. Top-3優先不確実性
4. 観測タスク（仮説/手順/判定/証拠/タイムボックス）
5. （full時）検証後、Decision proposalと必要なproposed Law案