---
name: wrap-decision
description: "WRAP 決策框架 — 認知偏誤防護、選項擴增與資料充足度閘門。用於防護自動駕駛、假選項、證據不足下的倉促決策。內含完整 premortem 流程（失敗原因並行深挖 + 綜合報告），適用版本規劃、提案評估、發版前等高成本決策。Use when: 被困住或連續失敗 2+、準備宣告限制性結論前、偏離核心目標、根因分析、代理人失敗歸因、提案評估、重大架構或規則決策、個人化建議（健康/醫療/金錢/法律）前、Context 沉重時、需要對計畫做事前風險推演時。Triggers: stuck, blocked, loop, no progress, 分析, debug, 限制性解法, 個人化建議, 具體推薦, premortem, 事前驗屍, 事前假設失敗, 壓力測試計畫, 這計畫會怎麼死, 找出盲點。"
---

# 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）

選定方案後、執行前：

1. 「用最有力的方式陳述被放棄選項的優點」
2. 「列出選定方案的三個缺點」

做得到 → 決策品質足夠；做不到 → 回到 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