Imported from tarrragon/screen_clock (
.claude/skills/wrap-decision/SKILL.md). Install upstream withnpx skills add tarrragon/screen_clock --skill wrap-decision. Copyright stays with the author.
WRAP 決策框架 Skill
框架結構：錨點確認 → Step 0（資料充足度閘門）→ W（擴增選項）→ R（現實檢驗）→ A（拉開距離）→ P（準備好犯錯）→ 絆腳索（持續監控）
核心理念：提醒決策者「你是有選擇的」，不替決策者做選擇。
本 SKILL 為通用 WRAP 規則，獨立於任何專案框架。專案若需要掛鉤（Hook）、CLI 或任務系統整合，請在該專案內另建落地層文件。
觸發條件
| 情境 | 識別特徵 | 模式 |
|---|---|---|
| 連續失敗 | 同一問題修改 2+ 次仍失敗 | 快速 |
| 被困住 | 表達「做不到」「沒辦法」「不支援」「禁止」「不可能」 | 快速 |
| 偏離核心 | 連續 2+ 個任務單位不在當前迭代目標 | 完整 |
| 重大決策 | 影響架構/流程/版本方向的非技術決策 | 完整 |
| 救火排擠 | 花 > 30 分鐘在非原定計畫的問題上 | 快速 |
| 分析任務 | 根因調查、代理人失敗歸因、測試失敗檢討 | 快速+（配合兩階段反思） |
| 根因深度反思 | 用戶質疑「分析太表層」「不夠深」、或需要把失敗歸因寫成可重用規則 | 完整 WRAP 強制：先列 5+ 候選假設 + 現實檢驗（Reality Test） + 2 層深因，再用 W/A/P 檢驗 |
| 反思深度質疑 | 用戶要求「太表層」「再想想」「更深一層」「還有其他可能」「反向驗證」 | 完整 WRAP 強制：先擴增假設，再做反向驗證，最後回到可執行結論 |
| 提案評估 | 評估提案可行性 | 完整 |
| 不可逆 / 時間壓力 | 一旦執行難以回退，或須在很短時間內定案 | 完整（重 P 階段回退計畫） |
| 利害關係人衝突 | 多方目標不一致、需平衡不同立場 | 完整（重 W 假選項偵測） |
| 個人化建議 | 使用者用「我」「我該」「推薦給我」，或話題涉及健康/運動/裝備/金錢/法律/醫療 | Step 0 強制 |
| CLI / 規則自動駕駛（autopilot）（決策路徑層 3.1） | CLI 撞錯後立即重試或猜變體（非查 --help / 規則文件） |
快速（強制查文件後再試） |
| 既有結論錨定（Anchor）（決策路徑層 3.2） | WRAP W 階段選項能一句話概括 / 全指向同一根因 | 完整（強制反向思考（Consider the Opposite） + 重新定義問題） |
| 規則失敗草率改規則（決策路徑層 3.3） | 失敗第一反應「改規則」，未先重試 2 次 | 快速（先挖根因再決定改規則或改行為） |
| 多步驟成功率盲點（決策路徑層 3.4） | 多步驟計畫中所有中間步驟都預測成功 | 快速（R 階段基本率 + 每步獨立驗證） |
| 完整 premortem | 版本規劃、提案評估、發版前等高成本決策，需要對「這計畫會怎麼死」做並行深挖 | 完整（P 階段展開版，見 references/premortem-workflow.md） |
| 二元處置取捨 | 準備向使用者呈現「保留 / 回退 / 停用 / 刪除」類處置選項，而該清單未經 W 階段產出 | W 階段起跳（反向框架 + 三類涵蓋跑完才列選項）；處置涉及防護能力增減或不可逆變更則升為完整 |
上述 4 項決策路徑層因子可由各專案映射到自己的掛鉤（Hook）、CLI 或任務系統；本 skill 只保留通用判斷語意。
二元處置取捨：與既有結論錨定（3.2）的邊界
兩者都處理選項空間過窄，觸發時機不同：既有結論錨定（3.2）在 WRAP 內部——W 階段已跑，發現產出的選項能被一句話概括；二元處置取捨在 WRAP 之前——尚未進入 WRAP，直覺已浮出一組對立選項並準備直接呈現。3.2 是自我檢查，本項是入場閘門。
Why：處置類問題（「這個東西該留還是該拿掉」）天然以對立軸呈現，直覺產生的選項清單會被「該多硬 / 該留多少」這種程度軸限定，而真正的解常在程度軸之外（移位、換執行點、重新定義對象）。選項一旦列出即封閉解空間，且該封閉對決策者不可見——決策者只會看到自己列了三個選項，不會看到沒被列出的第四個。
Consequence：使用者只能在被限定的清單內選擇，或必須自己看穿框架才能提出第四個選項。決策品質上限由列選項者的框架決定，而非由問題本身決定。
Action：識別到自己正要列處置類選項時停手，先跑 W 階段的反向框架檢查（原框架的反面是什麼？）與三類涵蓋（改造既有 / 零工具 / 新增工具），選項清單取自 W 階段產出。若 W 階段的產出與直覺清單一致，照列即可——最低成本是一次檢查，不是一次重寫。
升級條件：處置對象涉及防護能力增減（移除守衛、降級閘門、停用檢查）或不可逆變更時，W 階段不足，須跑完整模式。理由是這類處置的錯誤代價不對稱——R 階段的基本率與既有機制查證常會推翻 W 階段看似完整的選項集，而 A 階段的悖論檢查是「守衛是否誠實」這類問題的唯一結構化把關。
實證：某次面對「hook 出口被降級後該保留還是回退」的處置決策，直覺清單為三項（保留 / 回退 / 先複核）。跑 WRAP 後，W 階段反向框架把問題從「出口該多硬」重寫為「這個防護該不該存在於此執行點」，方案擴增至 5 項，使用者最終採用的方案不在直覺清單內。
本節為「二元處置取捨」判準的 substance 權威來源。
.claude/pm-rules/askuserquestion-rules.md「選項空間檢查」節為其專案層落地版本，兩節判準相同，修改請以本節為準並同步該節。
快速模式（5 分鐘）：錨點 + Step 0 + W + 基本率（R 核心）+ 機會成本（A 核心）+ 決定 快速+模式：快速模式 + 強制 R 的基本率 / 反向驗證兩階段反思（分析任務最容易跳過事證直接下結論，故在快速基礎上補回 R 核心 + 一輪反向驗證） 完整模式（15-30 分鐘）：全階段 Step 0 強制：個人化建議場景，不論採用哪個模式，Step 0 為必經閘門
各專案可依自身工作流建立機器可讀觸發條件、自動觸發機制、關鍵字清單對應，以及任務啟動階段的簡化三問（W/A/P 1-2 分鐘版）。
0. 錨點確認（Anchor Check）
進入分析前先確立錨點。
第一錨點 — 產品決策：
| 問題 | 目的 |
|---|---|
| 「誰是我們的客戶？」 | 建立決策錨點 |
| 「當前的核心目標是什麼？」 | 對齊迭代目標 |
第二錨點 — 流程決策：
| 問題 | 目的 |
|---|---|
| 「這個流程改善影響決策品質或開發效率嗎？」 | 區分「改善工具」vs「低價值維護」 |
| 「不做這個改善，會重複付出什麼代價？」 | 評估一次性投入 vs 持續回報 |
閘門判斷：
這個問題影響核心客戶 / 核心目標嗎？
├─ 是 → 進入 Step 0
├─ 否 → 這個流程改善影響決策品質或開發效率嗎？
│ ├─ 是且持續回報 > 一次性投入 → 進入 Step 0
│ ├─ 是但低回報 → 建提案（提案暫存區） → 回到核心任務
│ └─ 否 → 記錄待辦 → 回到核心任務
└─ 純粹救火 → 建任務單位 + 低優先級 → 回到核心任務
引用：英特普拉思特「病人才是我們的客戶」— 確立後，所有困難的決定都有了錨點。
Step 0. 資料充足度閘門（Data Sufficiency Gate）
核心問句：「我手上的資訊夠做這個決策嗎？還是我正在用假設替代資料？」
模式辨識
| 模式 | 特徵 | 答案來源 |
|---|---|---|
| 資訊查詢 | 問的是客觀知識（「X 和 Y 差別」「怎麼運作」） | 公開資料即可 |
| 決策諮詢 | 問的是「我該怎麼選/做/買」 | 必須基於當事人條件 |
使用者說「我是 X」、「推薦給我」、「我該買哪個」 → 決策諮詢。決策諮詢以個案資料為基準，群體平均值只作為背景參考。
判定流程
Step 0：資料充足度檢查
│
├─ 檢查 1：我知道當事人是誰嗎？（年齡/性別/身體/財務條件）
├─ 檢查 2：我知道當事人的目標嗎？
├─ 檢查 3：我知道當事人的限制嗎？（預算/時間/禁忌）
├─ 檢查 4：我知道當事人的環境嗎？（地區/可用資源）
├─ 檢查 5：我在用「平均值假設」替代「個人資料」嗎？
└─ 檢查 6：如果假設錯誤，後果會嚴重嗎？
│
▼
判定結果
├─ 資料充足 → 進入 W 階段
├─ 資料不足 + 低風險 → 進入 W，但標記假設
├─ 資料不足 + 中風險 → 暫停，漸進式問 2-3 個關鍵變數
└─ 資料不足 + 高風險 → 強制完整問卷 + 建議諮詢專業人士
為什麼 Step 0 必須在 W 之前
W 階段「擴增選項（Widen Options）」是「擴增選項空間」，但選項的意義取決於當事人條件。如果不先確認資料充足度：
| 表面現象 | 實際狀況 |
|---|---|
| 列出 A/B/C/D 四個選項（看似多元） | 四個選項都基於「用戶是平均值」的假設 |
| 對選項做現實檢驗（Reality Test） | 只是驗證「對平均值用戶是否可行」，非「對此用戶可行」 |
| Attain Distance 考量機會成本 | 比較的是錯誤假設下的成本 |
| Prepare to be Wrong | 預想的失敗原因都是技術性，忽略「假設錯誤」這個最大風險 |
結論：Step 0 缺失會讓整個 WRAP 流程變成「精美的錯誤分析」。
反模式偵測
| 警告信號 | 含義 |
|---|---|
| 擴增選項（Widen Options）時寫出「適合的用戶選 A，其他用戶選 B」 | 已承認用戶差異會影響選擇，卻未先確認用戶是哪種 |
| 選項描述含「通常」「一般來說」「大多數人」 | 用群體敘述替代個體判定 |
| 執行現實檢驗（Reality Test）時發現「數據來源是群體統計」 | 這屬於 Step 0 應提前檢出的問題 |
| Attain Distance 的機會成本計算需假設用戶偏好 | 偏好是 Step 0 資料，不該在 A 階段假設 |
失敗模式：Step 0 最容易被跳過是因為反問當事人打斷對話流暢度。流暢度與準確度的取捨應交由當事人決定。
各專案可建立個人化建議的三層機制（識別 / 分級 / 誠實）。
與 requirement-protocol 的分工邊界
Step 0（本閘門）、premortem 的 context 閘門、requirement-protocol 三者都做「資訊不足時先補齊再往下」，但受眾與問題不同，勿混用或重複建置：
| 機制 | 問的是 | 三問 / 檢查焦點 | 用於 |
|---|---|---|---|
| WRAP Step 0（本節） | 決策諮詢的當事人條件夠不夠 | 當事人是誰 / 目標 / 限制 / 環境（檢查 1-6） | 個人化建議、決策諮詢 |
| premortem context 閘門 | 要驗屍的計畫輪廓清不清楚 | 是什麼 / 影響誰 / 成功長怎樣 | 高成本決策的 premortem 前置（references/premortem-workflow.md 步驟 0） |
| requirement-protocol | 使用者指令是否明確可執行 | 模糊指令澄清、可決定 vs 該確認的邊界 | 收到開發指令、需求確認 |
共用原則：三者都遵循「一次一問、問到門檻即停、能推斷則不問」（見 .claude/rules/core/ai-communication-rules.md 規則 5 主體性保護）。Action：進入 WRAP 前若卡在「使用者到底要什麼」屬 requirement-protocol 範圍，先澄清指令；卡在「當事人條件」用 Step 0；卡在「計畫輪廓」用 premortem context 閘門。三者互為前置，不重複問同一組問題。
W — 擴增選項（Widen Your Options）
核心問句：「還有什麼其他方式可以達成目標？」
爬梯子法（由近到遠）
| 層級 | 搜尋範圍 | 做法 |
|---|---|---|
| 0. 身邊 | 當前專案既有程式碼/模組 | 搜尋既有 API |
| 1. 同層 | 當前專案其他模組的做法 | 檢查類似功能的實作 |
| 2. 同領域 | 社群（GitHub Issues、文件） | 網路搜尋 |
| 3. 跨領域 | 其他工具/框架的類比方案 | AI 內建知識調用 |
每層找到可行方案就停止，找不到才往上爬。
品質檢查
| 檢查 | 問題 | 不通過的信號 |
|---|---|---|
| 選項消失測試 | 如果以上選項全部被移除，還能怎麼做？ | 選項不足 → 框架太窄 |
| 假選項偵測 | 選項之間有實質差異嗎？ | 全部指向同一根因/同一途徑 → 季辛吉陷阱 |
| 框架測試 | 能否用一句話概括所有選項？ | 可以 → 選項多元性不足 |
| 方案性質三類涵蓋 | 候選方案是否涵蓋 新增工具 / 改造既有 / 零工具或純文件 三類？ | 全屬「新增工具」→ LLM 工具化偏誤（toolification bias），強制補「改造既有」與「零工具」選項 |
| 方案關聯性檢查 | 任兩方案是否可退化為同一方案或既有機制？ | 可退化 → 實質選項數量要重算（假多樣性） |
| 反向思考（Consider the Opposite） | 如果我相信的正好相反，會怎樣？真正該問的問題是什麼？ | 能提出有力相反論述 → 重新定義問題後從 W 重跑 |
反向思考（Consider the Opposite）是最容易被跳過但最重要的檢查 — 也是防止「在錯誤問題框架下擴增選項」的最後防線。詳細操作與範例見
references/detailed-techniques.md。
方案性質三類涵蓋與方案關聯性檢查用來抵抗 LLM 的工具化偏誤（toolification bias）：訓練資料常把「新增工具」寫成答案，卻忽略「改造既有機制」與「零工具」選項。即使補上多個方案，若方案間強關聯也可能退化為 1 個實質選項。
假設層級多元性（真正的擴增選項，Widen）
選項必須在「假設根因」層級多元，而不只是「實作手段」層級多元。
擴增選項（Widen）列出多個方案 ≠ 真正擴增了選項空間。若所有方案都接受同一個未驗證的根因假設，仍是偽擴增選項（pseudo-Widen） — 方案脫靶率會集中分佈（要嘛全中、要嘛全脫）。
最低操作：列方案前先寫出「我假設問題是 X 造成的」，再質疑 X 是否為真根因。
分析類任務（根因調查、設計決策）建議完整執行三層質疑、現實檢驗（Reality Test）閘門與警告信號檢查。
多輪迭代查詢（深度議題建議）
對複雜議題（如規則設計、提案評估），W 階段不應一次性完成擴增，採四輪迭代結構：
| 輪次 | 名稱 | 目的 |
|---|---|---|
| 1 | 發散型 (Divergent) | 廣泛關鍵字鋪面建立問題地圖 |
| 2 | 具體化 (Concrete) | 將抽象主題轉為具體案例 |
| 3 | 精準化 (Precise) | 從前兩輪提煉精準關鍵字深挖 |
| 4 | 反向驗證 (Inverse) | 對結論找反例 / 批評 / 反駁 |
進入下一輪訊號（至少 3 條）、邊界條件、實證統計詳見 references/iterative-research.md。
R — 現實檢驗（Reality-Test Your Assumptions）
核心問句：「需要什麼事證才能證明這個方法可行？」
基本率 > 預測
| 壞問題（預測） | 好問題（基本率） |
|---|---|
| 「這樣改會成功嗎？」 | 「這類問題的常見解法有哪些？成功率？」 |
| 「我目前相信的根因會成功嗎？」 | 「這類症狀的常見根因分佈是什麼？」 |
| 「代理人會完成嗎？」 | 「這類任務耗盡資源的常見閾值是什麼？」 |
大範圍觀照（Zoom Out）+ 近距離檢視（Zoom In）
| 方法 | 做法 | 產出 |
|---|---|---|
| 大範圍觀照（Zoom Out） | 搜尋基本率：多少人遇到？常見解法？ | 統計性判斷 |
| 近距離檢視（Zoom In） | 讀具體案例內文、實際變更內容 | 直覺性判斷 |
兩者缺一不可：基本率建立基準，近距離檢視觸動直覺。
大範圍觀照（Zoom Out）前置確認（搜尋範圍校準）：
搜尋前問自己：「我搜尋的是問題本身的基本率，還是我預設解法的基本率？」
- 搜尋「tool call 閾值校準」→ 預設解法的基本率（狹窄）
- 搜尋「為什麼要拆分任務」→ 問題本身的基本率（廣闊）
清單類答案的來源核對
LLM 列清單時最容易產生幻覺（會「補齊」看起來合理的項目）。現實檢驗（Reality Test）對清單類答案必須執行逐項對 source 核對，禁止整批信任。
最低規則：
- 找到該領域的權威 source（官方 docs、本機 spec、Context7）
- 清單每一項對照 source；找不到 → 標記為候選幻覺
- 單項細節（schema、欄位語意）比整體清單可信
完整防護重點是幻覺模式分類、逐項核對流程與反模式識別；各專案可另建來源清單與核對模板。
R.2 事實宣稱驗證（ANA → IMP 派發前強化）
核心問句：「這個 ANA 結論的關鍵假設是什麼？我用什麼指令驗證過？」
R 階段一般處理「基本率」「來源核對」（已有「清單類答案的來源核對」段），但對 ANA 結論落地為 IMP 派發前的具體事實宣稱（如「Hook X 已強制 Y」「函式 F 已存在」「規則 R 已涵蓋場景 S」）需額外做主線程驗證——這類宣稱常被當作前提，但驗證成本極低且漏驗代價可能很高。
何時必做：
- ANA 結論引用「Hook 已強制 / 已實作 / 已涵蓋」等事實狀態
- 動作不可逆（刪除規則 / 修改 auto-load 層）
- ANA 含 dissenting view 對某假設提出疑慮（devil's advocate 警告）
驗證動作：grep / ls / wc / 讀程式碼確認事實狀態與 ANA 假設一致。
驗證失敗處理：在 IMP ticket Problem Analysis 補「主線程驗證後的範圍調整」段，禁止直接照原 ANA 結論派發。
案例集 + 完整觸發條件：
.claude/references/dispatch-pre-validation-cases.md（首例 W10-137 — 救下「直接刪 ticket-skill-sync-check.md」誤刪決策） 入口：.claude/pm-rules/dispatch-gate.md關卡三
試水溫（Ooch）
對每個選項問：「能否用最小成本驗證？5 分鐘內能得到初步答案嗎？」
- 能 → 先試水溫再決策
- 驗證成本高 → 進入完整分析
最強版本論證（Steelman）
選定方案後、執行前：
- 「用最有力的方式陳述被放棄選項的優點」
- 「列出選定方案的三個缺點」
做得到 → 決策品質足夠；做不到 → 回到 R 階段補充。
反向驗證範本（深度議題建議）
對結論做反向搜尋避免確認偏誤。標準格式：
| 我們的結論 | 反向搜尋目標 |
|----------|-----------|
| [結論] | [批評 / 反例 / 反駁 / 限制] |
至少涵蓋 4-8 種反向方向類型（學術批評 / 反方論點 / 失效情境 / 統計限制 / 文化限制 / 家長主義（paternalism）警示 / 取捨揭露（trade-off） / 自我參照悖論）。
詳見 references/iterative-research.md 「反向驗證實踐範本」章節。
A — 拉開距離（Attain Distance）
核心問句：「投入這個問題的時間，會擠壓哪個更重要的目標？」
前置強制檢查
進入 A 前必完成以下 4 項檢查，任一觸發即回 W 階段重擴增。
| 檢查項 | 問題 | 觸發條件 |
|---|---|---|
| 框架概括測試 | 能否用一句話概括所有候選方案？ | 「能」→ 選項多元性不足，回 W |
| 反面框架識別 | 問題的反面框架是什麼？（例：「如何擋 X」的反面是「為何會有 X」） | 未列出反面框架即進 A → 強制停下列出 |
| 相反論述檢視 | 反向思考（Consider the Opposite）：若我相信的正好相反會怎樣？真正該問的問題是什麼？ | 能提出有力相反論述 → 重新定義問題後從 W 重跑 |
| 工具選擇檢查（Tool selection check） | 物化 / 步驟數 / 目的地 / 白名單 4 問（見下） | 任一問暴露繞路 → 回 W 換 1 步工具 |
工具選擇檢查（Tool selection check）觸發條件：選工具（tool）前 + 預估步驟數 > 2 + 涉及 Write/Bash 組合（例如 Write 暫存檔再 Read 再 Bash 寫入）。
Tool selection 4 問：
| 問題 | 核心 | 範例（反模式 → 正確） |
|---|---|---|
| Q1 物化檢查 | 我是否把「解決方案」物化為「工具」（「用 Write 建檔」），而非解決「問題」（「把文字寫進任務紀錄」）? | 「Write /tmp/ctx.md 再 Read 再 bash append」（物化）→「heredoc append」（解決問題） |
| Q2 步驟數檢查 | 選擇路徑的實際步驟數是 N? 有無 1 步路徑被忽略? | 3 步（Write→Read→Bash）→ 1 步（heredoc Bash 或 Edit 任務紀錄） |
| Q3 目的地檢查 | 工具產出目的地是 CLI/檔案系統? 匹配需求嗎? | 目的是寫進任務紀錄 → 首選 Edit / heredoc CLI，避免多餘中介檔 |
| Q4 白名單檢查 | 目前工具是否在「低摩擦首選」名單外（偏好 heredoc Bash / Edit 直接編輯，次選 Write 類）? | 長文寫入任務紀錄首選 Edit 或 cat <<'EOF' heredoc |
違反防護的代價：A 階段方案比較表面周詳，實際全指向同類型解法；或單步最優化但總步驟盲，把多步繞路誤判為簡單方案。
完整 4 問操作細節見
references/detailed-techniques.md「工具選擇檢查（Tool selection check）詳細技巧」章節。
機會成本顯性化
每個選項強制列出：
選項 A：[做法]
機會成本：花 X 時間，這段時間可以 [替代用途]
風險：[可能失敗的條件]
不選其他的代價：[放棄什麼]
引用：DVD 實驗 — 只加上「不買，留下 14.99 美元買別的」，不買率從 25% 升到 45%。顯性化機會成本能改變決策。
10/10/10 規則
| 時間 | 問 |
|---|---|
| 10 分鐘後 | 這個決定當下的感受 |
| 10 個月後 | 這個決定對使用者/專案的影響 |
| 10 年後 | 這個決定對整體生態/信任度的影響 |
核心優先事項對齊
| 問題 | 目的 |
|---|---|
| 「這個決策服務於哪個優先事項？」 | 對齊 |
| 「如果優先事項衝突，哪個排第一？」 | 排序 |
| 「投入這問題的時間，擠壓哪個更重要的目標？」 | 機會成本 |
排序確定後，低優先事項的決策自動有答案 — 記錄延後，不投入時間。
提案系統對接
使用「安全停放區」承接暫緩想法：想法被記錄，並明確標示目前聚焦的工作。
| 系統 | 角色 |
|---|---|
| 提案暫存區 | 安全停放區 — 記錄想法，不代表要做 |
| 任務追蹤系統（pending） | 承諾清單 — 已決定要做，排入排程 |
| 迭代目標文件 | 核心優先事項 — 當前迭代的目標 |
悖論識別檢查清單（規則 / Skill / 掛鉤（Hook）設計時必檢）
設計規則 / 流程 / 系統時，必對 5 條檢查清單逐項自檢：
- 此規則是否本身違反它要保護的價值？
- 此規則是否通過善意家長主義（benevolent paternalism）4 條件測試？（實質傷害 / 介入有效 / 利益大於風險 / 最小限制）
- 此規則的「正確示範」是否本身違反它要禁止的模式？
- 此規則的設計者立場是否被透明化？
- 此規則是否預留「用戶可覆蓋」機制？
詳見 references/anti-paternalism.md（含規則設計中的家長主義（paternalism）悖論案例）。
P — 準備好犯錯（Prepare to Be Wrong）
核心問句：「假設這個方案失敗了，最可能的原因是什麼？」
決策確定後、執行前，完成四項檢查：
| 檢查 | 問題 | 判斷 |
|---|---|---|
| 行前預想（Premortem） | 假設 12 小時後失敗了，列出 3 個最可能原因 | 任一原因可能性 > 50% → 重新評估 |
| 未來區間 | 最好的結果？最壞的結果？ | 兩端都能接受嗎？ |
| 安全係數 | 預估時間/資源 x 1.3-1.5 | 緩衝夠嗎？ |
| 回退計畫 | 失敗怎麼回退？回退成本？ | 回退成本 > 收益 → 重新評估 |
Gary Klein 方法：先假設計畫失敗了，然後問「是什麼殺了它？」比問「可能會失敗嗎？」多產出 25% 的洞察（且更具體）。
每個預想失敗原因配早期警訊：行前預想列出 3 個原因後，為每個原因補 1-2 個可觀測的早期警訊——能實際看到或量到的訊號（如「測試 flaky 率 > 5%」「某 API 回應時間翻倍」），不是模糊感覺（如「感覺會出問題」）。Why：預想的失敗原因若無對應訊號，只是行前焦慮，無法在執行中被偵測；配上可觀測訊號後，失敗模式從「事後才知道」變成「訊號亮起即介入」。Action：警訊只需行前預想時記在 ticket；若某警訊需要跨 session 持續監測，包裝為監測 ticket 並綁定 trigger（.claude/rules/core/decision-trigger-binding.md 規則 2：合法 trigger 限 ticket ID，量化閾值須先包裝為 ticket），不可寫「之後再觀察」式無 trigger 延後。
高成本決策的完整展開版：上表「行前預想」是 12 小時尺度、3 原因的簡化版，適用一般 ticket。版本規劃、提案評估、發版前等高成本決策改用完整 premortem 流程——原因數量不設上限、每個原因獨立派 subagent 深挖、輸出三分綜合報告（含每原因的早期警訊），見 references/premortem-workflow.md。
自我暴露偏好實踐（提供建議時必行）
提供建議時必暴露偏好、推理鏈、盲點，不偽裝中立：
| 實踐 | 禁止 | 正確 |
|---|---|---|
| 暴露偏好 | 假裝中立提問 | 「我傾向 X，理由 Y」 |
| 暴露推理鏈 | 只給結論 | 列出推理步驟讓用戶可追溯 |
| 暴露盲點 | 假裝完整考慮 | 「我可能漏掉的角度有 Z」 |
| 標記偏誤 | 標成推薦（Recommended） | 改為「我目前的猜測」或不標 |
Voss 自陳：「one person's influence is another person's manipulation」——影響力的本質取決於是否被透明化。推薦標記（Recommended）已被學術界（DarkBench）列為 LLM 暗黑模式（dark pattern）。
詳見 references/anti-paternalism.md 「自我暴露偏好實踐」章節。
5. 絆腳索（Tripwire）
核心理念：絆腳索不保證做出正確決定，但讓你意識到「是該做決定的時候了」。
絆腳索類型
| 類型 | 觸發條件 | 動作 |
|---|---|---|
| 期限型 | 非核心問題花 > 15 分鐘 | 建任務延後，回到核心 |
| 失敗型 | 同一修改連續 2 次失敗 | 搜尋社群或換方向 |
| 偏離型 | 連續 2+ 個任務不在當前迭代目標 | 回到核心任務 |
| 回退型 | 已回退過一次 | 完全停止，換方向 |
| 嘗試型 | 同一問題修改嘗試 2 次 | 向外求解 |
| 資料充足度 | 進入決策諮詢前 | 強制 Step 0 閘門 |
| 基礎設施累積型 | escalation 連續 2+ 次、每次加一層工具 / 檔案 / 流程、anchor 未曾明說 | 亮 anchor 一次（為誰 / 為什麼 / 對不對外）、按它重定 apparatus 份量 |
完整類型（含正面絆腳索 — 捕捉意外成功）、命名效應、切割機制見
references/tripwire-catalog.md。
階段間切割點
WRAP 每階段之間是切割點 — 強迫問「是否繼續」：
- Step 0 完成 → 「資料夠了嗎？還是需要先問？」
- W 完成 → 「選項品質夠嗎？」
- R 完成 → 「證據支持哪個選項？」
- A 完成 → 「這符合核心優先事項嗎？」
- P 完成 → 「行前預想的風險可接受嗎？」
與其他決策類 Skill 的關係
| Skill 類型 | 分工 |
|---|---|
| 技術方案比較（3+ 方案比較） | 方案比較用專用 skill；認知偏誤防護用 WRAP |
| Bug 證據驅動修復 | 明確 bug 用證據驅動修復 skill；被困住/連續失敗用 WRAP |
| 任務認知負擔評估 | 任務拆分用專用 skill；決策品質用 WRAP |
| 決策格式模板（5W1H） | 格式模板負責「怎麼寫」；WRAP 負責「怎麼想」 |
| 學習捕捉 | WRAP 的正面絆腳索串接學習捕捉 skill |
參考文件
通用（可跨專案複用）
| 文件 | 內容 |
|---|---|
references/detailed-techniques.md |
每階段的詳細技巧、範例、書中引用（DVD 實驗、努金調解、季辛吉陷阱、Gary Klein 方法） |
references/pm-checklist.md |
快速模式 + 完整模式檢查清單 + 決策品質自測 |
references/tripwire-catalog.md |
絆腳索類型完整目錄、自動駕駛失敗模式、切割機制、命名效應 |
references/iterative-research.md |
多輪迭代查詢方法論（4 輪結構：發散 → 具體化 → 精準化 → 反向驗證 + 進入下一輪訊號 + 反向驗證 8 種類型範本） |
references/anti-paternalism.md |
悖論識別檢查清單 + 自我暴露偏好實踐（善意家長主義（benevolent paternalism）4 條件測試、自我參照悖論識別、推薦標記（Recommended）是暗黑模式（dark pattern）） |
references/claim-quick-wrap.md |
任務啟動的簡化三問（W/A/P 1-2 分鐘版）、快速模式進一步壓縮版 |
references/premortem-workflow.md |
完整 premortem 五步流程（context 閘門 → raw 失敗原因列舉 → 並行深挖 subagent → 三分綜合報告 → 落檔），為 P 階段簡化三問的高成本決策展開版；含本框架落地約束章節（PCB 派發骨架、markdown 落檔限制），其他專案沿用時可調整該章節 |
Last Updated: 2026-08-04
Version: 2.9.0 — 「二元處置取捨」節補一則權威標註：本節為該判準的 substance 權威來源，.claude/pm-rules/askuserquestion-rules.md「選項空間檢查」節為對應落地版本，消除兩節間逐字重複的 Why/Consequence/實證段
Version: 2.8.0 — 移植 blog 分支獨有演化（來源：blog 分支 2.4.0 + 2.5.0 合併）：觸發條件表新增「不可逆 / 時間壓力」「利害關係人衝突」兩項；新增「快速+模式」定義（原僅見於觸發條件表值，未定義語意）；參考文件表補 claim-quick-wrap.md（原 canonical 已有該檔但未被引用，至今 orphan）；絆腳索類型表新增「基礎設施累積型」（escalation 連續 2+ 次、每次加一層工具 / 檔案 / 流程而 anchor 未曾明說時，亮 anchor 一次按其重定 apparatus 份量）。
Version: 2.7.0 — 觸發條件表新增「二元處置取捨」項（入場閘門：處置類選項未經 W 階段產出即不得呈現），並補與既有結論錨定（3.2）的邊界說明——3.2 是 WRAP 內部自我檢查，本項是 WRAP 之前的入場閘門。
Version: 2.6.0 — Step 0 資料充足度閘門新增「與 requirement-protocol 的分工邊界」子節：三機制（WRAP Step 0 / premortem context 閘門 / requirement-protocol）受眾與問題對照表 + 共用原則（一次一問、互為前置不重複），requirement-protocol 反向交叉引用同步（1.5.0-W5-009.7，源自外部 premortem skill context 充足度閘門）。
Version: 2.5.0 — P 階段「行前預想」新增「每個預想失敗原因配早期警訊」條款：可觀測訊號（非模糊感覺）+ 需跨 session 監測時包裝為監測 ticket 綁 trigger（decision-trigger-binding 規則 2）（1.5.0-W5-009.6，源自外部 premortem skill early warning signals）。
Version: 2.4.0 — 新增完整 premortem 流程（references/premortem-workflow.md）：failure-reason 並行深挖 + 三分綜合報告，銜接 P 階段簡化三問與理論依據 principles/premortem-klein.md；description 補觸發詞（premortem/事前驗屍/壓力測試計畫等）（1.5.0-W5-009.5）。
Version: 2.3.0 — 觸發條件新增 4 項決策路徑層干擾（CLI 自動駕駛（autopilot） / 既有結論錨定（Anchor） / 草率改規則 / 多步驟成功率盲點）；既有觸發條件不變動（向後相容）。
Version: 2.2.0 — 觸發條件新增反思深度質疑（reflection_depth_challenge）說明，含與被困住語意的差異。
Version: 2.1.0 — 新增多輪迭代查詢方法論（W）+ 反向驗證範本（R）+ 悖論識別檢查清單（A）+ 自我暴露偏好實踐（P）+ 2 個新 references（iterative-research / anti-paternalism）。
Source: 《零偏見決斷法》(Decisive) — Chip Heath & Dan Heath