# Assumption Audit

> 設計・仕様・計画に埋め込まれた前提を洗い出し、未検証の前提が判断を歪めていないかを確認する。設計レビュー前、ADR作成前、重要な技術選定前に使う。

- Skill: `thinkyou0714/assumption-audit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add thinkyou0714/assumption-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thinkyou0714/assumption-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: thinkyou0714 (https://skillmd.com/u/thinkyou0714)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thinkyou0714/assumption-audit

---


## Purpose

「当たり前と思っていた前提」が間違っていた、または未検証のまま設計が進んでいる状況を早期に発見する。
前提の可視化によって、判断の根拠を明確にし、見直しコストが低い段階でリスクを潰す。

## Use When

- 設計書・仕様書のレビュー前
- ADR（設計決定記録）の作成前
- 技術選定・アーキテクチャ決定の前
- 「なぜこうなっているのか」の根拠が曖昧な場合
- issue-framing の後に前提をより深掘りしたい場合
- 実装前に「このまま進んでよいか」を確認したい場合

## Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

- **対象**: 前提を洗い出す対象（設計書・仕様・方針・会話ログ等）
- **判断の背景**: なぜこの設計・方針になったか（わかる範囲で）
- **懸念点**: すでに気になっている前提・違和感（ある場合）
- **判断の時期**: この設計がいつ決まったか（情報が古い可能性の確認）

## Output Contract

以下の順で出力すること。順序を変えない。

1. **論点**: この設計・方針に埋め込まれた前提の核心は何か
2. **根拠**: その前提をそう判断した理由・出典
3. **リスク**: 前提が崩れた場合の影響（コスト・時間・品質・ユーザー影響）
4. **含意**: 前提の検証結果が示す設計上の意味
5. **改善案**: 前提を検証・修正するための具体的な手順
6. **代替案**: 前提を取り除いた場合の別設計・別アプローチ
7. **判断材料**: 前提の妥当性を判断するために人間が確認すべき情報

## Review Lens

- **目的妥当性**: 洗い出した前提が、本来の目的と整合しているか
- **範囲の過不足**: 重要な前提を見落としていないか。細かすぎる前提を拾いすぎていないか
- **中長期リスク**: 今は正しくても将来崩れうる前提はないか
- **LAB全体との整合性**: LMS / 自動化 / データ設計との前提矛盾がないか
- **非エンジニア理解可能性**: 前提の説明が、非エンジニアにも伝わる言葉か
- **他LLM移植耐性**: Claude 固有の解釈・推論に依存した前提整理になっていないか

## Instructions

1. 対象テキストを読み、明示的な前提（「〜だから」「〜を前提に」等）を抜き出す
2. 暗黙の前提（「当然〜だろう」として書かれていない前提）を推定・列挙する
3. 各前提を以下の3分類に振り分ける:
   - **検証済み**: 根拠がある、または実測・実験済み
   - **合理的推定**: 根拠はないが現時点では妥当と考えられる
   - **未検証**: 根拠なし、または確認が必要
4. 未検証の前提を優先度順にランク付けする（影響が大きいもの優先）
5. 各未検証前提に対して「どう検証するか」を具体化する
6. 前提が崩れた場合の影響（コスト・スケジュール・品質）を見積もる
7. 不明な前提は推測せず「要確認」として明示する

## Guardrails

- 前提の正誤を自分で断定しない。「未検証」「検証済み」の分類に留める
- 推測で前提を補完しない。「前提として確認が必要」と明示する
- 前提が崩れた場合の代替案を必ず1つ以上示す
- 検証方法が「誰かに聞く」だけで終わらないよう、具体的な確認先・確認項目を示す
- コスト影響（修正工数・機会損失）を省略しない
- 人間が最終的に前提の妥当性を判断する余地を残す

## LAB Cross-Check

実行結果に対して以下を確認すること。

| 観点 | 状態 | 備考 |
|---|---|---|
| 自動化フロー | — | 自動化の前提条件が未検証ではないか |
| データ / 認証 / ログ | — | スキーマ・権限モデルの前提が正確か |
| 実装 / 運用フロー | — | 技術的な前提（ライブラリ・API仕様等）が古くないか |
| 非エンジニア理解可能性 | — | 前提整理が非エンジニアにも説明できる形か |
| 会員共有 / 再利用耐性 | — | 前提が LAB 固有すぎて他ケースに使えないか |
| 他LLM移植耐性 | — | Claude 固有の推論に依存した分類になっていないか |

状態は OK / 注意 / NG / 対象外 で記入すること。

## Handoff Notes

施工AI へ渡す前に以下を確定させること。

- **要件**: 検証が必要な前提の一覧（優先度付き）
- **成功条件**: 各前提の検証方法と、「検証済み」と判断できる基準
- **失敗条件**: 前提が崩れた場合の影響範囲と判断基準
- **実行範囲**: 前提検証のために確認してよいファイル・DB・外部API
- **影響範囲**: 前提の修正が波及する設計・実装の箇所
- **ロールバック方針**: 前提修正に伴う設計変更が失敗した場合の戻し方
- **コスト比較**: 「前提を検証してから進む」vs「前提をそのまま進む」のコスト差

## Further Reading

- `issue-framing` skill — 前提洗い出し前の論点整理に使う
- `risk-scan` skill — 前提崩壊のリスクを深掘りしたい場合に使う
- [docs/DECISIONS.md](../../../docs/DECISIONS.md) — 過去の設計決定と前提を確認する
- `boundary-check` skill — 前提に関わるスコープの境界を確認したい場合に使う