安装此技能
npx skills@latest add mattpocock/skills --skill=to-questionnaire 然后在你的编码 agent 里输入 /to-questionnaire 。
本页目录
它做什么
to-questionnaire 把一个你自己定不下来的决定变成一个问卷（questionnaire）：一份 markdown 文档，你把它交给那个掌握你所缺信息的人，让他们异步填写，或者你们两人在会议上一起过一遍。
它就发送（send）质询你，从不质询主题。一场关于主题的访谈没有意义，因为不知道主题正是你要去问别人的原因。所以它问两件你总能回答的事（这份问卷要发给谁，你需要从他们那里拿回什么），并把文档里的每个问题都对准两者之间的缺口。
什么时候用它
你通过输入 /to-questionnaire 来调用它；agent 不会主动去拿它。
当一个决定被卡在只存在于另一个人脑子里的知识上时，就用它：一位客户、一位领域专家、一位掌握业务规则的高管、一位和你不在同一个团队共事的同事。你想要哪个技能，取决于答案在哪里：
| 答案在…… | 该用哪个 |
|---|---|
| 你自己的脑子里，还没磨锋利 | grill-me |
| 代码库里 | grill-with-docs |
| 别人的脑子里 | to-questionnaire |
| 还不在任何人的脑子里，这个问题需要有东西可以反应 | prototype |
常见情形是一场质询（grilling）会话卡住了，因为它提出的有些问题不该由你回答。在同一场对话里运行 /to-questionnaire，把那些问题带走处理，然后把答案带回来继续。
要问的是发送，不是主题
访谈是两次交流，然后它就停下。
- 这份问卷要发给谁？ 他们的角色、他们的专长、他们与你的关系。这决定了语气，以及文档必须携带多少上下文。一位外部客户需要被引导；一位队友不需要。
- 你需要拿回什么？ 那些你无法独自解决的具体决定或事实。这会变成最终文档的检查清单。你点名的每一项都会得到一个对准它的问题。
此后的一切都是起草。技能把文件写到当前目录下的 to-questionnaire-<slug>.md。没有配置，没有工作区，也没有任何东西需要设置。
文档
这份文档是一份发现问卷（discovery questionnaire），因为你缺少上下文，而接收方（recipient）拥有它。这决定了它的形状：
- 一行目的说明，点名那个依赖它的决定，再加一个简短的上下文小节，给一位对你的背景一无所知的接收方。
- 问题按最重要的在前排序，并分在带主题的标题下，因为异步意味着你可能只有一遍机会。
- 每个问题只装一个想法，绝不复合，问题下面有一个回答占位，只在某个问题可能被误读的地方加一行这为什么重要。
- 明确允许回答「我不知道」，因为一个被标记出来的不确定性是有用的，而一个读起来像事实的自信猜测不是。
- 一个收尾的兜底问题：有没有什么我们没问、但我们应该知道的？
这份文档刻意不是两样东西。它不是分支式（branching）的。这些问题是扁平的、分组的清单，不是一棵「如果你回答 A 就跳过 D 节」的树。它也不是多接收方的。一次运行只给一个人产出一份文档。
常见问题
它会读我的质询会话并从中提取问题吗？ 不作为它自己的一个步骤。这个技能没有摄取阶段。它问关于发送的事，然后起草。让它在一次质询会话之后能用的是：你在同一场对话里运行它，所以这场会话（session）已经处在上下文（context）里，起草可以从中取材。如果你在一场全新的会话里启动它，它对那场质询一无所知，而你在回答「你需要拿回什么？」时得自己再把主题提供一遍。
缺的答案并不都在同一个人那里。它能按接收方拆开吗？ 不能。第一步问的是那个接收方，单数，技能把整份文档的语气和上下文都对准他们。如果三个人分别掌握答案的三个部分，就运行三次，每人一次。人们要求过一份能按学科或角色给问题分流的文档，但那没有随附发布。
这些问题是相互依赖的吗：它会根据前面的答案跳过某些小节吗？ 不会。依赖式问题的设计被探索过，但没有随附发布。输出是一份静态文档：按主题分组、最重要的在前、每个问题都生效。对它的反对意见是公允的。一个在真实答案出现之前就只提前规划两三个问题的模型（model），规划得很差；而一份分支式文档必须在每个答案出现之前就把所有问题都规划好。
如果接收方也不知道呢？ 文档会告诉他们要这样说。它明确要求「我不知道」和部分答案。一个被标记出来的不确定性比一个猜测更有价值，因为一个含糊的答案和一个自信却错误的答案，一旦回到你的上下文里，看起来一模一样。
它会把它发到什么地方吗（Slack、issue 追踪器、email）？ 不会。它把一份 markdown 文件写到当前目录，并告诉你路径。投递是你的事：把它粘贴进一个工单（ticket），把它丢进一个 Slack 讨论串，把它附到一封 email 上，或者把它打开在一块共享屏幕上现场过一遍。人们把这四种都手动做过。
这不就是批处理模式的 /grill-me 吗？
不是。grill-me 本来就按轮次提问。它一次问出整个开放问题的前沿，然后根据你的答案重新计算，所以它已经满足了「一次给我所有问题」这个需求。to-questionnaire 在另一个维度上不同。它关心的是答案在谁的脑子里，而不是问题如何送达。要自己更快地回答这些问题，用 grill-me。要从别人那里把它们取出来，用这个。
我就不能不用技能、直接让 agent 做这个吗？
能，而且在它存在之前很多人就是这么做的：OPEN_QUESTIONS.md 文件、发给客户的电子表格、每个未回答的问题一张「needs more info」工单。这个技能为你换来两样东西：访谈永远不会漂到主题上去，以及文档会以一个非技术接收方也能填写的形状出来。如果你已经有一个行之有效的内部格式，你就不需要这个。
它生效的标志
- 它问接收方，也问你需拿回什么，然后就停止提问。如果它问主题本身，这个技能就已经出错了。
- 你点名为「我需要拿回什么」的每一项，都能在文件里追溯到一个问题。
- 这些问题读起来是对准了接收方知道的东西，而不是你自己那些开放问题被逐字抄下来。
- 你能把文件交给一个不在那场对话里的人，而他们会知道自己为什么会收到它、以及什么时候之前要回复。
- 回来的答案是一轮新质询可用的输入，而不是一组新的问题。
它在体系中的位置
to-questionnaire 是一个随时可用的独立技能（Standalones）。你用在你自己的知识到头、而下一步是去问另一个人的地方，而不是去运行另一个技能。这最常发生在流程中途，当规划卡在一件不该由你决定的事情上。
它的邻居是 grill-me，两者在答案住在哪里的问题上不同。质询从你这里拿答案；问卷从别人那里拿答案。把回来的东西喂给另一轮质询，或者如果工作正走向一次构建，喂给 grill-with-docs 或 to-spec。当你不确定此刻哪个技能合适时，ask-matt 会为你路由。