| name | grill-me |
| description | 把模糊的功能想法逼成具體的 PRD。一次問完所有關鍵問題，存成 md 檔讓使用者
填答，迭代到對齊後產出 PRD draft，再交給 create-plan 寫詳細計畫。當使用者
說「grill me」、「拷問」、「釐清需求」、「想做 X 但很模糊」、「幫我把想法
變具體」、「pre-PRD」時觸發。**只做需求對齊，不寫程式、不寫 plan**。
|
| allowed-tools | Read, Write, Edit, Bash |
Grill Me
把模糊的功能想法逼成具體的 PRD。批次提問、md 迭代，直到對齊後交給 /create-plan。
Initial Response
收到 seed 後：
- 若 seed 超過 3 句話，先說「請把想法濃縮成 1–2 句，避免我順著你的方向走而失去拷問價值」
- 若 seed 提到具體檔案或 code，先讀取它以了解背景
- 決定 slug 與路徑後，立即寫入 Round 1 md，再提示使用者填答
Process
Step 1: Receive Seed
接受 1–2 句的模糊想法作為 seed。
若使用者一開始給長篇規格（>3 句），要求濃縮：
「這個描述很詳細，但 grill 的價值在於從零逼出破綻——請把想法縮成一句話，
讓我從最基本的角度開始問。」
Step 2: Decide Slug & Path
從 seed 語意生成 slug（英文小寫、hyphen 分隔、≤4 個字）。
路徑判斷：
- 若
thoughts/ 目錄存在：寫到 thoughts/shared/grill/YYYY-MM-DD-<slug>.md
- 否則：寫到
grill/YYYY-MM-DD-<slug>.md（在當前工作目錄下建立）
用 date +%Y-%m-%d 取得今天日期。
Step 3: Write Round 1
套用 md Template，填入：
- seed 原文
- 5 核心問題（每次都問）
- 動態加題（依 seed 內容判斷是否加入）
寫入後在 chat 告知路徑：
「已建立 <path>，請在每題 A: 下方填入答案，填完後回到 chat 說「答完了」。」
Step 4: Wait for Answers
等待使用者填答。不要在這個階段追問。
使用者填完後會說「答完了」或執行 /grill-me review <md path>。
Step 5: Review & Decide
讀取 md 檔，逐題評估答案的「具體程度」：
具體的判斷標準：
- 有明確邊界（誰、哪些場景、哪些不在 scope）
- 有可量測的描述（數字、狀態、行為）
- 沒有「視情況」「看看再說」「之後再決定」這類模糊詞
若 ≥1 題答案仍模糊：
- 在 md 的
## Round N Questions 下追加新一輪問題（只問模糊的那幾題的 follow-up）
- 更新 frontmatter：
status: awaiting-answers，rounds: N
- 在 chat 說「我在 md 追加了 Round N 問題，請繼續填答。」
若全部答案夠具體：
- 填寫
## PRD Draft 區塊（套用 PRD Draft Template）
- 更新 frontmatter：
status: ready-for-plan
- 移至 Step 6
Step 6: Handoff
PRD Draft 填好後，在 chat 說：
「PRD 已寫入 <path>，狀態為 ready-for-plan。
下一步：/create-plan <path>」
5 核心問題（每次都問）
以下 5 題每次 Round 1 都問，不可省略：
- 誰會用 / 誰刻意不服務？ —— 使用者邊界
- 失敗或降級時怎麼辦？ —— 錯誤處理與 fallback
- 怎麼知道成功？怎麼知道失敗？ —— 量測指標（含領先 / 落後指標）
- 為什麼不用現成方案？為什麼不直接不做？ —— 替代方案與機會成本
- 明確 out of scope 是什麼？ —— v1 / v2 切點
動態加題判準
依 seed 內容決定是否追加以下問題（每條最多加 1 題）：
| seed 出現關鍵詞 | 追加問題 |
|---|
| 資料、DB、ETL、bigquery、表、欄位 | 資料來源、量級、是否需要回溯歷史？ |
| UI、頁面、介面、按鈕、表單 | edge case：空狀態、權限視圖、異常輸入分別怎麼處理？ |
| API、Cloud Run、外部服務、webhook | rate limit、認證方式、配額上限、retry 策略？ |
| 部署、上線、release、rollout | rollout 策略、回滾觸發條件、是否需要 feature flag？ |
若上述都不符合：不加題（最多 7 題總量：5 核心 + 2 動態）。
md Template
每次建立新 grill md 時使用此格式：
---
seed: "<原始 seed 文字>"
created: <YYYY-MM-DD>
status: awaiting-answers # awaiting-answers | reviewing | ready-for-plan
rounds: 1
---
# Grill: <slug>
## Seed
<原始 seed，1–2 句>
## Round 1 Questions
### Q1: 誰會用 / 誰刻意不服務？
// FEEDBACK:
### Q2: 失敗或降級時怎麼辦？
// FEEDBACK:
### Q3: 怎麼知道成功？怎麼知道失敗？
// FEEDBACK:
### Q4: 為什麼不用現成方案？為什麼不直接不做？
// FEEDBACK:
### Q5: 明確 out of scope 是什麼？
// FEEDBACK:
<!-- 動態加題（若有）放在這裡 -->
## PRD Draft
<!-- status = ready-for-plan 時填 -->
## Notes
<!-- 自由區，使用者可寫雜記 -->
PRD Draft Template
當所有問題對齊後，填入 ## PRD Draft 區塊（≤30 行）：
## PRD Draft
### Problem
<2–3 句>
### Users
- In: <誰用>
- Out: <誰不服務>
### Success Metrics
- <指標 1>
- <指標 2>
### In Scope (v1)
- <項目 1>
- <項目 2>
### Out of Scope
- <項目>
### Open Risks
- <風險>
### Design Concept
<一段話描述這東西是什麼，作為 create-plan 的入口>
不要做的事
- 不寫程式碼 —— grill-me 只做需求對齊
- 不寫 implementation plan —— 那是
/create-plan 的工作
- 不要一題一題問 —— 永遠 batch 問完再等使用者填答
- 不要把明確答案打回去重問 —— 答案夠具體就接受，不要為了「問得更精確」而反覆追問
- 不要 proactive trigger —— 只在使用者主動呼叫時啟動
- 不要自動接
/create-plan —— 讓使用者手動執行，不自動串接
- 不要整合 plan-ceo-review —— 兩者完全獨立，不做任何形式的整合
