---
name: uncertainty-map
description: >-
  Map prototype assumptions on a Core/Peripheral × Verified/Partially-verified/
  Unverified 2x2 grid and visualize it, to surface the riskiest unverified
  assumptions and what to validate next. Use when the user wants 不確実性マップ,
  仮説検証マップ, リスクマップ, 何を検証すべきか, 次に何を検証, RAT, Riskiest Assumption,
  validation map, assumption map, or wants to turn a vision / prototype /
  docs/feature-list.md into a prioritized validation backlog.
disable-model-invocation: false
rank: core
categories:
  - business
---

# Uncertainty Map

Map prototype assumptions on a 2x2 grid — **Core/Peripheral × Verified(✅)/Partially-verified(🟡)/Unverified(⬜)** — and **visualize it**, so the team sees the riskiest unverified assumptions and what to validate next. The visual map is the deliverable; it doubles as the artifact you show others.

The skill **stands alone**: it works from a vision, a prototype, or `docs/feature-list.md` if present — but never requires another skill's output and never depends on cross-skill ID traceability. When a feature list exists it is a useful seed, and the relationship is **iterative** (you go back and forth between features and assumptions), not a one-way downstream step.

> Human-facing overview: [README.md](README.md). Detailed references: [references/](references/).

## When to use

- "不確実性マップ / 仮説検証マップ / リスクマップ を作って"
- "次に何を検証すべき / Riskiest Assumption / RAT"
- The user wants to triage a validation backlog after (or alongside) a prototype

There is one mode — a single map with its visualization. The map itself is what you share; there is no separate stakeholder report.

## When NOT to use

- Vision / one-line statement → use [product-vision-and-concept](../product-vision-and-concept/SKILL.md)
- Use case extraction → use [function-usecase-map](../function-usecase-map/SKILL.md)
- Feature list / product backlog → use [feature-backlog-map](../feature-backlog-map/SKILL.md) (iterative neighbor, not a hard prerequisite)
- Prototype design judgment (feel/surface) → use [prototype-design-md](../prototype-design-md/SKILL.md)
- Recording validation results / observation evidence → use the `validation-log` skill
- Customer-facing 矢羽 / Go/No-Go dates → use [delivery-phase-plan](../delivery-phase-plan/SKILL.md)
- Owner / RACI / staffing → use [delivery-team-plan](../delivery-team-plan/SKILL.md)

## Reference router

| Task | Doc |
|------|-----|
| Confirm inputs, hybrid intake, standalone fallback | [references/intake.md](references/intake.md) |
| Extract assumptions (粒度・ID) | [references/assumption-extraction.md](references/assumption-extraction.md) |
| Decide Core vs Peripheral (axis 1) | [references/core-vs-peripheral.md](references/core-vs-peripheral.md) |
| Decide Verified / Partial / Unverified (axis 2) | [references/verification-classifier.md](references/verification-classifier.md) |
| Output + visualization template (`docs/uncertainty-map.md`) | [references/matrix-template.md](references/matrix-template.md) |
| 4-quadrant action playbook + 14 validation methods (#1-9 価値系 / #10-14 技術系) | [references/action-playbook.md](references/action-playbook.md) |
| Coverage / anti-slop / quality gate | [references/quality-checklist.md](references/quality-checklist.md) |
| Self-evaluation scenarios (Layer B/C) | [references/eval-scenarios.md](references/eval-scenarios.md) |
| Pass/fail rubric for evaluations | [references/eval-rubric.md](references/eval-rubric.md) |

Read reference files at the relevant step. Do not load all upfront.

## Entry-point shortcuts

| Situation | Flow |
|-----------|------|
| Vision (+ feature-list) + プロト実装 ある（新規）| Step 0 → 1 → 2 → 3 → 4 |
| `docs/uncertainty-map.md` 既存（検証スパイク後の更新）| Step 0 (diff-update) → 3 (昇格/降格判定) → 4 |
| プロト未実装、vision のみ | Step 0 → 1 → 2 → 3 (全件 ⬜) → 4 |
| 観察ログだけ追加された | Step 0 (diff-update) → 3 sub-step 3 (✅ 昇格判定) → 4 |
| 技術スパイク / PoC / ベンチマーク結果が追加された | Step 0 (diff-update) → 3 sub-step 3 (技術仮説の ✅ 昇格判定 — outcome 数値必須) → 4 |
| Vision / feature-list 不在 | Step 0 → single-turn interview → `(コア候補)` ラベル |

Announce the chosen flow in one line before Step 4 emit.

## Workflow

### Step 0 — Confirm inputs (hybrid intake)

Read [references/intake.md](references/intake.md). The skill is **standalone** — gather inputs in this priority order, none mandatory:

1. `docs/product-vision.md` (if present) — vision yardstick for axis 1
2. `docs/feature-list.md` / `docs/product-backlog.md` (if present) — assumption seeds and an optional 紐付 F column
3. `DESIGN.md` and prototype implementation files (`git ls-files`) — axis 2 evidence
4. Observation / measurement logs — promote 🟡 → ✅
5. Single-turn dialog when seeds are missing

If vision and feature-list are both missing, mention `/product-vision-and-concept` and `/feature-backlog-map` once, then proceed with a single-turn assumption interview (label each assumption `(コア候補)`). Never block on upstream skills.

**Diff-update mode**: when `docs/uncertainty-map.md` already exists, default to incremental update — surface 新規/昇格/降格/削除 diff and preserve existing A IDs. ✅ への昇格は観察根拠が必須（実装済 ≠ 検証済）. Full regeneration only when the user says "ゼロから作り直して". See [references/intake.md](references/intake.md) §Diff-update mode.

### Step 1 — Extract assumptions

Read [references/assumption-extraction.md](references/assumption-extraction.md).

- One feature / goal produces 0..N assumptions. Surface implicit beliefs as testable statements.
- **NEVER** restate the feature name as an assumption (parrot anti-pattern).
- A ID rule: `A-<Seq>` (e.g. `A-01`, 2-digit zero-padded). When a feature list exists, record the feature in a 紐付 F column (`F-NN`); when it does not, leave 紐付 F as `—`.
- Each assumption must be falsifiable in one sentence.
- **Separate technical from value beliefs**: 「実装してみないと分からない型」(feasibility / performance / integrability / non-determinism / rendering behavior) は **価値仮説と別 A ID** に分ける。1 仮説に混在させると refute 時に原因が判別できない。識別が必要なら `-T<n>` (技術) / `-V<n>` (価値) サフィックスを使う。

### Step 2 — Axis 1: Core vs Peripheral

Read [references/core-vs-peripheral.md](references/core-vs-peripheral.md).

Apply 3 yardsticks in order until a definitive answer:

1. **Vision** — does failing this assumption break the one-line vision? → Core
2. **High-priority mapping** — does it back a high-priority (top-of-PBL) story / feature? → Core
3. **Otherwise** → Peripheral

Each assumption MUST carry a 1-line rationale citing vision quote / 紐付 F + priority / cost trade-off. If the user pressures to mark everything Core, refuse and downgrade.

### Step 3 — Axis 2: Verification status (3 labels, hybrid)

Read [references/verification-classifier.md](references/verification-classifier.md). Run 5 sub-steps:

1. Seed every assumption as `⬜ 未検証`
2. Probe codebase: `git ls-files`, then grep for feature name keywords / test files; promote to `🟡 部分検証` when implementation+tests exist
3. Promote to `✅ 検証済` only when **observation / measurement evidence** is present — scale + period + outcome の 3 点必須。価値仮説はユーザー観察、技術仮説はスパイク / PoC / ベンチマーク / Web Vitals 等の **計測 outcome**（成功数 / p95 / 有効率 / CLS など機械可読な数値）
4. Single-turn dialog: present the inferred matrix, ask only for diffs
5. Lock in (axis1, axis2) pair per assumption

**NEVER** mark `✅` without observation evidence. Animation of code passing tests is `🟡` only. 「スパイクで動いた」だけの outcome も 🟡 据え置き — 計測値が必須。

### Step 4 — Emit & cross-check

Read [references/matrix-template.md](references/matrix-template.md).

- Build the **visualization** first: Mermaid `quadrantChart` (+ ASCII fallback + 象限別件数表).
- For each assumption write a card: A ID, 仮説, 紐付 F, 軸1 根拠, 軸2 根拠, 推奨検証手段 (from [references/action-playbook.md](references/action-playbook.md)).
- Build the 次の検証アクション table for Core × Unverified rows (仮説 / 手段 / 工数 / 期待結果 / 失格条件).

Cross-check with [references/quality-checklist.md](references/quality-checklist.md) before write:

- **Coverage**: every high-priority feature / Core candidate has ≥1 assumption mapped
- **Action**: every Core × Unverified row has ≥1 validation action proposal
- **Honesty**: no fabricated user counts, observation periods, or measurement values

Write to `docs/uncertainty-map.md`.

## Final deliverable

Every session ends with the report block below — even partial / interrupted sessions. **Do not exit without it.**

```
✅ docs/uncertainty-map.md に出力しました
- 全仮説: <N> 件 / コア: <C> / 周辺: <P>
- ステータス: ✅<v> / 🟡<p> / ⬜<u>
- 最優先（コア × 未検証）: <n> 件 / 検証アクション提案済
- 差分更新: 新規 +<a> / 昇格 <pr> / 降格 <dm> / 削除 -<d>（diff-update mode のとき）
- 次の一手: 提案済み検証スパイクの実行 → 結果反映で再 mapping（feature-list とも行き来）
```

Output file shape (summary; full template in [references/matrix-template.md](references/matrix-template.md)):

- スコープ（vision / 対象プロト / 入力ソース）
- **可視化**: Mermaid `quadrantChart` + ASCII 図 + 象限別件数表
- 4 象限の詳細表（コア × 未検証 / 部分検証 / 検証済 + 周辺）
- 次の検証アクション表（仮説 / 手段 / 工数 / 期待結果 / 失格条件）
- カバレッジ・サマリ + 次の一手

## NEVER

- Mark `✅ 検証済` without user observation / measurement evidence (animations of green tests are `🟡` only)
- Place an assumption in Core without citing vision or a high-priority feature rationale
- Require another skill's output or cross-skill ID linkage to run
- Use a single validation method (e.g. "ユーザーテスト") for every action — pick from the 14-method playbook (#1-9 価値系 / #10-14 技術系)
- Apply "ユーザーテスト" to a technical hypothesis — feasibility / performance / non-determinism は #10-14 (スパイク / PoC / ベンチマーク / 品質変動計測 / 実装観察) で扱う
- Combine technical + value beliefs into a single assumption — refute 時に原因が判別できなくなる。必ず 2 仮説に分解する
- Restate a feature name as an assumption (e.g. "X ができる" is not an assumption)
- Fabricate user counts, observation periods, or measurement numbers

## MUST

- Produce the visualization (quadrantChart + ASCII fallback + counts) as the central deliverable
- Carry a 1-line rationale for each Core classification (vision quote or high-priority feature reason)
- Propose ≥1 validation action for every Core × Unverified row
- Record 紐付 F (`F-NN`) when a feature list exists; use `—` when it does not
- Use `—` for unverifiable cells; never invent metrics or user counts

## Principles

The stance behind the workflow. When references conflict with these, the principles win.

1. **Implementation ≠ verification** — ✅ requires user observation / measurement evidence (人数・期間・結果). Code passing tests is 🟡, not ✅.
2. **Core is narrow by design** — Core 判定は数を絞るのが目的。絞り込めない仮説は Peripheral に降ろす。Core は ≤30% を目安、超えたら理由を明示。本スキルの「コア仮説」は **Why の核**（vision を成立させる暗黙の前提）を指し、`feature-backlog-map` の機能（**What の核**）とは別レイヤー。高優先度の機能から抽出した暗黙の前提が「コア仮説」候補になる。
3. **Vision is the yardstick** — Core 根拠は vision 引用 / 高優先度の機能紐付 / cost trade-off のいずれかで 1 行書ける。「重要だから」は理由ではない。
4. **The map is the artifact** — 可視化された不確実性マップ自体が共有物。別途の対外レポートは作らない。マップを見れば「何が確かで、次に何を検証するか」が分かる状態を目指す。
5. **Falsifiable beliefs only** — 仮説は「これが間違っていたら ___」を 1 文で書ける。書けないものは仮説ではなく wish。
6. **Match method to belief** — 検証手段は 14 種カタログ（#1-9 価値系 / #10-14 技術系）から仮説タイプに応じて選ぶ。「ユーザーテスト」一択は思考停止。技術仮説（feasibility / performance / non-determinism / rendering behavior）はスパイク / PoC / ベンチマーク / 品質変動計測 / 実装観察で検証する。
7. **Failure threshold defines learning** — 各検証アクションに失格条件（数値）を必ず付与。期待値だけ書いて失敗判定がないと学びが歪む。
8. **Diff-update preserves history** — A ID は verbatim で維持、retired ID は再利用しない。検証履歴の追跡可能性を最優先。
9. **Technical ≠ value hypotheses** — 「実装してみないと分からない型」(feasibility / performance / integrability / non-determinism / rendering behavior) は価値仮説と **別 A ID** に切り出す。机上の技術調査は検証ではないが、スパイク / PoC / ベンチマーク / Web Vitals 計測など **観察可能な outcome** を伴う実装観察は正当な検証ループに乗る。
10. **Always land the deliverable** — Every session ends with the Final deliverable block, even when partial.

## Anti-patterns for the agent

- Asking the user clarifying questions one-by-one across many turns instead of one batched intake
- 推奨検証手段を 5 つ並べて選ばせる — 第一候補 1 つに絞り、代替は注記程度に
- Probing the codebase silently and reporting the matrix without showing it to the user before emit
- Looping the diff-confirmation dialog more than once before emitting
- 観察ログの数値を「だいたい」「数人」と曖昧に書く — 具体数値か `—` の二択
- Refusing to run because `docs/feature-list.md` is missing (it is optional — fall back to vision / prototype / single-turn interview)
- Loading all references upfront instead of on-demand at each step
- Promoting ⬜ → ✅ in one step (must pass through 🟡 with implementation+test evidence)
- 「動かしてるから検証済」「テストが緑だから検証済」と書く — 両方とも 🟡 まで
- Re-using a retired A ID in diff-update mode (always allocate next Seq)

## Self-evaluation loop

Run all three layers before declaring the skill ready or after edits. Full scenarios, prompts, and rubric live in [references/eval-scenarios.md](references/eval-scenarios.md) and [references/eval-rubric.md](references/eval-rubric.md).

1. **Layer A static**: `bash skills/prhythm-skill-review/scripts/validate-skill.sh skills/uncertainty-map`
2. **Layer B efficacy**: scenarios (new map / standalone fallback / diff-update / technical hypotheses) — pass when all rubric items observed
3. **Layer C discipline**: pressure scenarios — RED → GREEN → REFACTOR

If any layer fails, fix SKILL.md / references and re-run from Layer A. Stop after 3 cycles and revisit § Workflow or § Reference router.

## Documenting with prhythm-docs

After the skill run, when the user asks to save or present results（まとめて / ドキュメントにして / スライドにして）:

1. Use `/prhythm-docs` (or follow that meta-skill)
2. Fill `templates/docs/index.md` and `templates/docs/sections.html` in this skill
3. Build the deck: `node skills/prhythm-docs/scripts/build-deck.mjs skills/uncertainty-map/templates/docs/sections.html docs/prhythm/uncertainty-map/index.html --title "…"`
4. Write `docs/prhythm/uncertainty-map/index.md`

Do not dump full catalogs into those files. Markdown is a briefing (Answer / Frame / Evidence / Gates / Next) — see `skills/prhythm-docs/references/md-grammar.md`.