メニュー
不確実性を発見・台帳化し、優先順位付け・観測タスク化を経て、検証済み仮説をLaw（LDE）に昇格させる。使用タイミング: 不確実性/曖昧さ/未知/仮説/検証/調査/リスク/前提/優先順位/観測/意思決定の話題が出たとき、または検証結果のLaw化を求められたとき。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | uncertainty-resolution |
| context | fork |
| description | 不確実性を発見・台帳化し、優先順位付け・観測タスク化を経て、検証済み仮説をLaw（LDE）に昇格させる。使用タイミング: 不確実性/曖昧さ/未知/仮説/検証/調査/リスク/前提/優先順位/観測/意思決定の話題が出たとき、または検証結果のLaw化を求められたとき。 |
| argument-hint | "register-only" で台帳作成まで、"full" でLaw昇格まで（デフォルト: full） |
不確実性の発見からLaw昇格までを一貫して扱う。
| 値 | 実行範囲 |
|---|---|
register-only | Phase 1-2のみ（台帳作成+観測タスク化） |
full（デフォルト） | Phase 1-3すべて（Law昇格まで） |
引数なしは full として扱う。
1〜3行で明確化する:
assets/uncertainty-register.md テンプレートを使い、まず10個まで項目化する。
足りない場合のみ増やす。抜け漏れチェックには references/triage-questions.md を使う（不確実性の洗い出し観点リスト）。
各項目を「〜は本当に成り立つか？」の疑問文に整える。 既に観測で答えが出ているものは事実として別枠へ移す。
各項目に1〜5でスコアを付ける。詳細基準は references/scoring.md を参照（Impact/Evidence/Urgency/Effortの各レベル定義）。
Priority = Impact x (6 - Evidence) x Urgency / Effort
上位N（通常3〜5）を選ぶ。
上位Nについて assets/observation-task.md テンプレートを使い、各タスクに必ず含める:
観測方法の選択には references/observation-methods.md を参照（現物観測・証拠観測・知識観測の使い分け）。
破壊的・大量の作業に繋がる場合:
uncertainty_plan.json を出力python scripts/validate_uncertainty_plan.py uncertainty_plan.json で検証各項目を Validated / Rejected / Accepted に更新し、Evidenceを必ず残す。
意思決定が絡む場合は assets/decision-record.md テンプレートを使う。
$ARGUMENTS が register-only の場合はここで終了。
検証済み仮説をLaw-Driven EngineeringのLawに昇格させる。
Phase 2でValidatedになった仮説から、以下の全条件を満たすものを候補にする:
候補ごとにLaw Type（Invariant / Pre / Post / Policy）を判定し、Law Card案を生成する。 テンプレート・判定基準・変換パターン例は references/law-promotion.md を参照（昇格条件の詳細、Law Type判定表、Law Cardテンプレート、変換例、レポート形式）。
/eld-spec-card law で正式なLaw Cardとして作成assets/uncertainty-register.md - 台帳テンプレートassets/uncertainty-card.md - 個別項目の詳細テンプレートassets/observation-task.md - 観測タスクテンプレートassets/decision-record.md - 意思決定記録テンプレートより詳しい例は references/example.md を参照（MVPでオフライン機能を入れるかの意思決定例）。
入力: 「この機能、ユーザーが本当に必要か分からない。技術的にも不安。どう進める？」
出力:
デザインシステムの構築・運用を体系的に行うスキル。ドキュメント（要件定義・ブランドガイドライン）からDesign Tokens・コンポーネント体系・ガバナンスまでを一貫して設計する。思考フレームワーク（Double Diamond・Atomic Design・Design Tokens 3層）の適用、暗黙的デザイン判断の形式知化（DDR/QOC/RFC）、UIインベントリ収集（手動+MCP自動化）を統合する。ゼロから体系的に構築する用途向け。既存の単発UIから再利用可能な構造を抽出するにはrelational-design-pluginのdesign-system-backflowスキルを使用すること。Use when: 「デザインシステムを構築して」「デザインシステムを設計して」「デザイントークンを定義して」「デザイン原則を策定して」「UIインベントリを作って」「デザインガバナンスを設計して」「デザイン判断を記録して」と言われた時。
iOS/Androidモバイルアプリのデザインを体系的に行うスキル。Apple HIG・Material Design 3などプラットフォームガイドラインに準拠し、ナビゲーション・レイアウト・コンポーネント・モーション・アクセシビリティを適切に設計する。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「モバイルアプリをデザインして」「iOSアプリのUIを設計して」「Androidアプリの画面を作って」「モバイルのナビゲーションを設計して」「タッチUIを改善して」「アプリのアクセシビリティを対応して」と言われた時。
Webアプリの個別画面・コンポーネントのデザインを体系的に行うスキル。デザインプロセス・レイアウト・コンポーネント設計・インタラクション・アクセシビリティなどWebデザインの確立された手法を適用する。デザインシステム全体の構築・運用はdesign-system-builderスキルを使用すること。デザイン判断の観察・関係・仮説・撤回可能性をtraceとして残したい場合はrelational-design-pluginを使用すること。Use when: 「Webアプリをデザインして」「UIを設計して」「画面をデザインして」「レスポンシブ対応して」「アクセシビリティを改善して」「コンポーネントを設計して」「カラーパレットを決めて」と言われた時。
Use this skill when a design assumption, user segment, business goal, constraint, or product requirement has changed and you need to analyze which design hypotheses, decisions, artifacts, copy, or components should be retracted or revised. Requires a Relational Design trace session with recorded observations/relations/hypotheses/decisions to analyze against — not a general "redo this design" request.
Use this skill to critique an existing UI, frontend implementation, wireframe, flow, or visual design through Relational Design relations: user state, business intent, action risk, trust, information density, reversibility, accessibility, and implementation constraints. This is a relation-based critique, not a general design-methodology review — for platform-guideline or design-system compliance review, use design-plugin instead.
Use this skill after creating or reviewing a design artifact to extract reusable design-system knowledge: semantic tokens, components, variants, interaction rules, copy patterns, accessibility constraints, and governance notes. This only backflows structure out of an artifact that already exists — to build or govern a design system from scratch (Design Tokens layers, Atomic Design, DDR/QOC/RFC, UI inventory), use design-plugin's design-system-builder instead.