About subtraction-thinking
A productivity skill that prompts teams and agents to consider removing or simplifying before adding. It provides review questions, trigger rules, and decision tools for projects, workflows, and deliverables.
Key features
- 01Removal and simplification reviews
- 02Before, during, and after checkpoints
- 03Rules that trigger subtraction reviews
- 04Decision tools and prioritization
- 05Required subtraction-review output format
Use cases
- 01Review a plan before committing resources
- 02Simplify a customer journey or team process
- 03Assess proposed features and added steps
- 04Edit reports to remove redundant content
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/subtraction-thinkingin Claude Code to confirm it loaded.
Bundled filesreferences/tools.md
Details
From the project README減法思維 (Subtraction Thinking)
核心原則
人在改善任何事情的時候，會系統性地優先想到加法——加功能、加流程、加選項、加人手、加說明。減法的方向不會自然浮現，必須被強制提示。
減法思維的目標不是讓東西變少，而是讓每個部分都有存在的理由。豐富不是問題，冗餘和失焦才是。
它有兩個截然不同的方向：
| 方向 | 核心問題 | 舉例 |
|---|---|---|
| 移除 | 這個東西拿掉之後，真正的損失是什麼？ | 砍掉沒人用的方案選項、刪掉每週沒有結論的例行會議、移除顧客從未觸碰的服務環節 |
| 簡化 | 這件事可以用更直接的方式達到同樣效果嗎？ | 把三層審批壓縮成一層、把複雜定價方案重整成顧客看一眼就懂的結構、把十頁報告重組成讓決策者三分鐘內找到答案 |
在問「加什麼」之前，先問這兩個問題
1. 有什麼可以不做、或者停掉？（移除方向）
2. 現有的東西有沒有地方可以更直接、更清楚、更少摩擦？（簡化方向）
這兩個方向都沒有空間了，才輪到「加什麼」。
三個時點的減法審查
動手前
✦ Won't List：這次選擇不做什麼？為什麼？
✦ 最小有效版本：最少需要哪幾個部分，核心目的才能達到？
✦ 簡化優先：現有的東西有沒有地方可以先整理，而不需要新增？
✦ 驗證成本：有沒有更便宜的方式先確認這個方向是對的，再全力投入？
如果使用者沒有「Won't List」，主動提出建議版本再開始。
途中（每次準備新增某個東西時）
移除方向
✦ 拿掉它，核心目的會受損嗎？受損多少？（若不會 → 延後或不做）
✦ 有沒有更輕量的替代方式達到同樣目的？
✦ 加這個會讓整體變得更難理解、更難維護、還是引入新的例外情況？
簡化方向
✦ 加入之後整體路徑變長了嗎？有哪段可以合併？
✦ 這個新增是在解決問題，還是在繞過一個可以直接修掉的根本原因？
✦ 使用者、顧客、或下一個接手的人，看到這個東西需要花多少時間理解？
完成後
主動執行一輪減法審查，結論必須說出「建議移除或簡化的項目」，不能只給正面清單：
移除方向：
✦ 哪些部分其實可以整個拿掉，而不影響核心目的？
✦ 哪些東西是「以防萬一」加上去的，但實際上從未被用到或觸發？
✦ 哪些步驟、環節、或規則是因為不信任而存在，而不是因為真實需求？
簡化方向：
✦ 哪些部分可以合併？
✦ 哪裡讓人需要多想一下才能理解？
✦ 從使用者或顧客的視角，從開始到完成的路徑，有哪些不必要的彎路？
✦ 如果讓一個第一次接觸的人來看，他會在哪裡卡住？
強制觸發規則
遇到以下情況，必須暫停，先執行減法審查再繼續：
- 方案超過 5 個主要組成部分 → 問「哪 1–2 個可以移除或合併？」
- 新增了一個環節或角色來解決某個問題 → 先問「那個問題本身可以直接消掉嗎？」
- 出現「未來可以加...」「之後還可以擴充...」 → 標記為潛在範圍膨脹，要求說明觸發條件
- 出現「保險起見」「以防萬一」「多一個不會少一個」 → 直接挑戰這個假設，要求量化損失
- 成本、時間、人力在增加 → 問「移除或簡化哪些可以把它縮回來？」
- 改善方案只列出加法選項 → 強制補上「簡化現有」的選項一起評估
各場域的具體問法
商業決策
- 移除：「這個方案裡，哪些部分對最終決策沒有影響？」「停掉哪些事情，反而能讓重要的事做得更好？」
- 簡化：「這個決策路徑可以縮短到幾個步驟？」「誰是真正的決策者？中間有沒有不必要的審核層？」
服務設計 / 顧客體驗
- 移除：「哪些接觸點其實不需要我們介入，顧客自己就能完成？」「哪個步驟是為了我們內部方便而存在，而不是為了顧客？」
- 簡化：「顧客從有需求到完成，最短的路徑是什麼？現在的路徑和它差多少？」「哪個等待或摩擦最讓人放棄？能不能直接消掉它，而不是加一個補救功能？」
組織 / 團隊運作
- 移除：「這個會議如果取消，會有什麼真正的損失？」「這份報告有人真的在讀並且根據它做決定嗎？」「這個審批層存在的理由是什麼？」
- 簡化：「這個流程最初為什麼這樣設計？原來的理由現在還成立嗎？」「誰擁有這個決策？能不能讓他直接做，不需要經過多人確認？」
行銷 / 產品定位
- 移除：「這個方案有幾個選項？選項變少之後，顧客的選擇會變得更清楚還是更困難？」「這個功能有多少人真正在用？」
- 簡化：「顧客能不能一句話說清楚這個產品是做什麼的？如果不能，是什麼造成的？」「這個訊息從第一眼到理解需要幾個步驟？」
提案 / 報告撰寫
- 移除：「這個段落對讀者的判斷有影響嗎？沒有的話可以刪。」「有哪些內容說的其實是同一件事？」
- 簡化：「讀者需要的答案在哪一頁？能不能讓它出現在更前面？」「結論能不能一句話說完？」
程式開發 / 系統設計
- 移除：「有沒有明確的需求證據支持這個功能？」「這個抽象層有第二個使用場景嗎？」
- 簡化：「這段邏輯能讓人不看注釋就理解嗎？」「這個依賴是必要的，還是習慣性加上去的？」
輸出格式規範
輸出任何方案、規劃、報告時，必須包含：
【減法審查】
▸ Won't List：（這次選擇不處理的事，以及理由）
▸ 建議移除：（可以整個拿掉的部分，以及拿掉的理由）
▸ 建議簡化：（東西還在，但可以讓它更直接的地方）
▸ 需要留意：（如果繼續往現在的方向走，哪裡可能會變成不必要的複雜）
簡短場合至少加一行：
💡 減法提醒：[一句話指出可移除或可簡化的地方]
常見反模式
| 反模式 | 識別特徵 | 減法對策 |
|---|---|---|
| 層架屋 | 每一層都是在修補上一層造成的問題 | 往根本原因找，修掉根本，不是繼續往上加蓋 |
| 繞路解法 | 加一個新環節來解決現有流程中的某個摩擦 | 先問：那個摩擦本身可不可以直接消掉？ |
| 備案堆疊 | 「萬一 A 不行就用 B，萬一 B 不行就用 C」 | 先做一個，驗證之後再考慮備案 |
| 選項膨脹 | 加更多選項讓方案看起來更完整 | 更多選項不等於更好的方案，問顧客或使用者真正需要的是哪個 |
| 承諾競爭 | 提案列越多項目顯得越認真、越有誠意 | 每個項目都要能說明它對目標的具體貢獻，說不清楚的先拿掉 |
| 沉沒成本抗刪 | 「都做了一半，刪掉很可惜」 | 已投入的成本不是繼續的理由，問的是繼續做的邊際價值 |
| 預防性複雜 | 「先把這個做好，之後要改比較方便」 | 沒有明確的需求證據，不先為未來設計 |
| 複雜度包裝 | 把複雜的東西說成「彈性」「可擴展」「全面」 | 問：現在真的需要這個彈性嗎？誰需要？什麼時候會用到？ |
減法決策工具
詳細工具說明與模板請參考 references/tools.md
- 移除評估：這個東西的存在理由是什麼？拿掉的真實損失是什麼？有沒有更輕量的替代？
- 路徑分析：畫出現有路徑 → 標出每個節點對核心目的的貢獻 → 合併或移除貢獻不清楚的節點
- 優先排序：Must（不做就壞）/ Should（有價值但可延後）/ Could（加分但非必要）/ Won't（這次不做）
- 選項評估：把「不做」和「簡化現有」列為正式選項，跟加法選項一起評分比較
- 假設驗證：在全力投入之前，用最小成本先確認核心假設是否成立
執行提醒
使用這個 skill 最大的失敗模式是：走完了減法審查的形式，但沒有真正找出冗餘或失焦的地方。
成功標準不是「更短」或「更少」——豐富的輸出沒有問題。成功標準是：每個部分都有存在的理由，沒有任何東西是靠慣性或習慣留下來的。
減法不是目的，但它是改進時最常被跳過的方向。強制把它放進來，才能讓加法的選擇是在真正評估過之後做出的，而不是預設值。