指令用途

/to-questionnaire 把一個你無法獨自回答的決策，轉成一份 Markdown 問卷，給唯一能回答的那個人 —— 可異步填寫，或在會議中一起走過。

它與 /grill-me（磨你自己）是相反的：/grill-me 追問主題，/to-questionnaire 追問發送。因為一場正常的追問會訪談主題，而這正是你這裡答不出來的，所以訪談只問：問卷要給誰、你需要拿回什麼，然後把每個問題瞄準兩者之間的缺口。

運作流程

1. 誰會收到這份問卷？ 弄清楚收件人是誰、他們的脈絡、他們的詞彙；你與他們之間的關係。完成於：你確切知道這份要寄給誰、為什麼是他們、以及他們帶什麼脈絡來讀。
2. 你需要拿回什麼？ 一次交換中，問出你無法獨自解決、需要從這人拿到的特定決策或事實。完成於：你有一份具體清單，寫著使用者必須能帶走去做或決定什麼。
3. 撰寫問卷：針對步驟 1-2 的缺口草擬問題。寫到當前目錄的 to-questionnaire-<slug>.md（slug 取自主題）。完成於：檔案存在，且使用者在步驟 2 點名的每個項目都被一個問題覆蓋。

核心：追問發送，而非主題

關鍵在於它不改主題。一般的追問 session 會訪談主題（「這個專案要做什麼？」「資料模型是什麼？」），但這正是你無法回答的部分 —— 如果你能答，你就不需要問卷了。

所以這個 skill 的訪談只涵蓋發送：

• 收件人是誰、他們懂什麼、他們的詞彙是什麼？
• 你需要從他們拿回什麼、哪些決策只有他們能下？

然後把每個問題都瞄準兩者之間的缺口 —— 收件人能答、你需要、你答不出來的。

實戰對話範例

範例一：需要法務確認的條款

• You:

  我們的隱私政策要用哪家第三方分析，但我不確定 GDPR 合規性。

• AI:

  進入 /to-questionnaire。這份要寄給誰？

• You:

  法務的 Sarah。

• AI:

  好。步驟 1 — 收件人脈絡：

  • Sarah 是法務，懂 GDPR 但可能不熟 web 分析工具的術語。
  • 所以問題要用她的詞彙（「資料處理者」「合法基礎」），避免 GA、Mixpanel 這類她未必熟的產品名。

  步驟 2 — 你需要拿回什麼：

  • 需要她判斷：Google Analytics 在我們的使用情境下，是否符合 GDPR？
  • 需要她判斷：若不符合，需要哪些配套（同意書、DPA、anonymize IP）？

  確認這兩點？確認後我寫 to-questionnaire-gdpr-analytics.md。

範例二：產品決策問業務負責人

• You:

  我不確定這個功能要不要做付費牆。

• AI:

  誰能拍板？

• You:

  產品負責人 Alex。

• AI:

  步驟 1：Alex 懂業務與付費轉換，但不一定熟技術成本。 步驟 2：你需要的是 —— 「這個功能要不要付費牆？」這個決策本身，以及背後的取捨假設。

  我會把問題瞄準只有 Alex 能答的（商業模式、轉換目標），技術成本由你這邊提供，不丟給他。

問卷文件結構

產出的 to-questionnaire-<slug>.md 是一份可直接寄出或會議共用的 Markdown：

• 開頭：一句話說明問卷目的、收件人是誰。
• 背景：收件人需要的最少脈絡（不過載）。
• 編號問題：每題瞄準一個你答不出來、收件人能答的缺口。
• 可選的選項：若是選擇題，給選項 + 各自的 implic 簡述。

何時應該使用

• 你答不出來的決策，有唯一能答的人：法務、PM、領域專家、客戶。
• 異步走得通：不必當場答，可填寫。
• 會議前準備：把問卷帶進會議一起走過。

何時不應該使用

• 你自己能答：那用 /grill-me 追問自己。
• 需要的是調查事實而非人意見：用 /research 查一手來源。
• 多個人均等可答、沒有「唯一」：那更像問卷調查，不適合本 skill 的「唯一能答者」前提。

與其他技能的關係

/to-questionnaire 是 /grill-me 的鏡像 —— 後者挖你自己，前者挖別人。在 /ask-matt 的路由中，它被框為「反過來的 /grill-me」。不確定該用哪個 skill 時，用 /ask-matt 來路由。