Assumption audit

Skill thinkyou0714/claude-lab-skills/lab-thinking-core/skills/assumption-audit

THINK YOU LAB thinking-OS skills for Claude Code — reusable judgment/design/automation/communication skill packs (tech-agnostic, MIT)

Install

npx -y skills add thinkyou0714/claude-lab-skills --skill assumption-audit

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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

SKILL.md

5.8 KB, as published. Nobody here has run it

Purpose

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

Use When

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

Inputs

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

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

Output Contract

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

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

Review Lens

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

Instructions

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

Guardrails

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

LAB Cross-Check

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

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

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

Handoff Notes

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

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