Change / Improve） 是做什麼的？
一句話鉤子：先別動手——動手之前先回答「用戶到底要什麼、有多複雜、從哪裡切入」三個問題。
它是「分診台」——不預設領域、不替你執行。把模糊想法變成結構化需求，把任務堆變成帶路由的執行順序，把現成方案變成可改進清單。然後明確指出下一個該用的 skill，自己不接活。
本 skill 是路由器，按用戶問題分派到三個子 skill：
growme-mode—— 需求澄清（「幫我想想」）change-mode—— 任務分診（「先做哪個」）improve-mode—— 結構優化（「怎麼改」）
核心定位
任何「不太確定從哪下手」的請求，都先走本 skill 一次。三個動作：
- 澄清（growme）：把模糊想法變成可執行需求
- 分診（change）：把任務堆變成執行順序
- 改進（improve）：把現成方案變成可優化清單
回答用戶的三個本質問題：
- 你到底要什麼？（growme 輸出「需求規格」）
- 該從哪開始？（change 輸出「執行順序」）
- 現在這樣對嗎？（improve 輸出「改進點」）
路由分派規則
收到用戶輸入後，先判斷屬於哪種模式（可多選、可串行）：
| 用戶特徵 | 模式 | 例子 | 路由到 |
|---|---|---|---|
| 表達了結果但路徑不清晰 | growme | 「我想做一個 AI 教學 skill」 | growme-mode |
| 有多個任務需要排序或選擇 | change | 「我手上有 8 個 skill 要精修」 | change-mode |
| 已有方案但不確認是否最優 | improve | 「你看這個 SKILL.md 寫得對不對」 | improve-mode |
判定原則：
- 多數請求先做 growme（澄清），再決定要不要串 change / improve
- 串行順序：growme → change → improve（先搞清楚要什麼，再排序，再審查方案）
- 明確告知用戶當前判斷的模式，讓用戶確認或糾正
- 不需要分診時直接說「不需要」，不要為了用 skill 而用
- 單次對話內可能涉及多個模式——按需串行調用
不要路由回自己：分診完必須指向其他執行 skill，不允許「做完 A 後再用 requirement-clarifier 澄清」。
觸發場景
強觸發（直接調用）：
- 「幫我想想 / 這個怎麼做 / 我有個想法」 → growme-mode
- 「這些任務怎麼排序 / 先做哪個 / 有哪些實現路徑 / 幫我分診」 → change-mode
- 「怎麼優化 / 還有什麼問題 / 幫我看看這個方案 / 審查一下」 → improve-mode
弱觸發（上下文裡有「不確定」語義時調用）：
- 收到一句話需求 + 沒有驗收標準
- 任務一摞 + 沒說依賴關係
- 已有方案 + 用戶表達「感覺哪裡不對」
- 團隊多人對同一目標描述不一致
不觸發（明確邊界）：
- 訊息已完全清楚 → 直接開幹，不要為了用 skill 而用
- 單個明確小問題（「X 怎麼用」）→ 用
AskUserQuestion直接問 - 已經是具體領域問題（「前端按鈕怎麼寫」）→ 路由到
frontend-design/ui-ux-pro-max等領域 skill - 純寫作/純翻譯/純生成 → 路由到
original-writing/humanizer/content-rewrite
輸出格式（路由器視角）
模式判斷：growme / change / improve（可組合）
【growme】 → 載入 growme-mode（執行需求澄清）
【change】 → 載入 change-mode（執行任務分診）
【improve】 → 載入 improve-mode（執行結構優化）
下一步建議：[具體路由到 XX skill / 直接執行 / 進一步澄清]
文件結構（本套件）
requirement-clarifier/ ← 路由器（你在這裡）
├── SKILL.md ← 本文件：路由 + 觸發 + 邊界
├── growme-mode/ ← 子 skill 1：需求澄清
│ ├── SKILL.md
│ └── references/
│ ├── seven-dimensions.md ← 7 大追問維度
│ ├── ask-question-toolkit.md ← AskUserQuestion 使用技巧
│ └── red-flags.md ← 常見假澄清反例
├── change-mode/ ← 子 skill 2：任務分診
│ ├── SKILL.md
│ └── references/
│ ├── complexity-rubric.md ← 複雜度判斷尺
│ ├── priority-matrix.md ← P0/P1/P2/P3 矩陣
│ ├── routing-table.md ← 30+ skill 路由對照表
│ └── parallel-dependency.md ← 依賴與並行
├── improve-mode/ ← 子 skill 3：結構優化
│ ├── SKILL.md
│ └── references/
│ ├── seven-leverage-points.md ← 7 類改進點
│ ├── smart-criteria.md ← SMART 原則
│ └── red-flags.md ← 假改進反例
├── examples/ ← 真實案例
│ ├── fake-clarification.md ← 假澄清反例樣本
│ ├── fake-triage.md ← 假分診反例樣本
│ └── fake-improve.md ← 假改進反例樣本
├── test-prompts.json ← 6 個活體測試樣本 + 自檢問題
├── README.md ← 套件門面（house-style 模板）
├── LICENSE ← MIT
└── .claude-plugin/
└── marketplace.json ← plugin 雙通道
打磨報告已移到
精修skills/13-元skill與治理/打磨報告/requirement-clarifier-打磨報告.md（集中存檔，便於看所有 skill 打磨情況）。
Gotchas（路由器層）
❌ 不要做的事
- 不要「代替執行」——本 skill 是「分診台」不是「手術室」。澄清和分診完成後明確指向下一個執行 skill
- 不要「為了用而用」——如果用戶輸入已足夠清晰，直接確認即可
- 不要「領域預設」——不預設前端、後端、內容、商業等任何領域
- 不要「路由回自己」——分診完不指向 requirement-clarifier，形成「分診→執行→驗證」閉環
- 不要「跳過 growme 直接 change」——任務堆的前提是「已經清楚要什麼」，否則先澄清
- 不要「一次問超過 5 個」——多於 5 個 = 你沒在抓重點
- 不要「改進點超過 7 個」——多於 7 個 = 你沒在排序，在羅列
✅ 判斷完成度的標準
輸出前問自己：
「用戶拿這份輸出能直接開幹嗎？」
- 能 → 完成
- 不能 → 哪一步還缺？回去補
- 拿不準 → 標註「需用戶確認 XX 後再開幹」
何時讀取子 skill
- growme 相關請求 → 載入
growme-mode/SKILL.md+references/seven-dimensions.md - change 相關請求 → 載入
change-mode/SKILL.md+references/priority-matrix.md+references/routing-table.md - improve 相關請求 → 載入
improve-mode/SKILL.md+references/seven-leverage-points.md - 完成度自檢 → 讀取本檔案 Gotchas 節
字數與結構
- SKILL.md 本體（路由器）：≤ 200 行（當前 ~150 行，達標）
- 子 skill SKILL.md：≤ 250 行
- 子 skill references/：按需載入，不灌進主上下文
- 總骨架檔案數：≤ 20