assumption-auditlisted

## 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つ以上示す - 検証方法が「誰かに聞く」だけで終わらないよう、具体的な確認先・確認項目を示す - コスト影響（修正