/to-questionnaire 技能

它的作用

to-questionnaire 把无法独自敲定的决策变成 questionnaire ——一份交给唯一持有你所缺之物的那个人的 Markdown 文档，让他们异步填写，或让你们两人在会议上一起过。

它就 send，而不是被审问的对象。在这里审问你这个话题毫无意义：不懂这个话题正是你要写信问别人的原因。所以它只问你总能回答的两件事——这份文档给谁，以及你需要他们回给你什么——并把文档中的每个问题都对准 gap 两者之间。

何时使用

你通过输入 /to-questionnaire ——这个 agent 不会自动调用它。

当一个决策被只存在于另一个人脑中的知识阻塞时使用它：客户、领域专家、掌握业务规则的高管、不在你团队的同事。你想要哪个技能取决于答案实际在哪里：

常见情况是 追问审视 停滞的会话：浮现的一些东西不由你回答。运行 /to-questionnaire 在同一个对话中把那些问题离线处理，然后把答案带回来继续。

发送对象，而不是主题

审问只有两轮往来，然后就停。

• 它要给谁？ 他们的角色、专长、与你的关系。这定下语气和文档必须承载的上下文量——外部客户需要被引入门，队友不需要。
• 你需要什么回复？ 你无法独自解决的具体决策或事实。这成为完成文档被衡量的检查清单：你点名的每个条目都会得到一个对准它的问题。

那之后的一切都是起草。文件落在 to-questionnaire-<slug>.md 在当前目录中。没有配置、没有工作区、无需配置任何东西。

文档

它被表述为 发现问卷 ——你缺少上下文，接收者持有它——而正是这个框架决定了它的形态：

• 一行目的说明，点明它承载的决策，以及一段写给从未进过你脑子的接收者的简短背景说明。
• 问题排序 most-important-first 并按主题标题分组，因为异步意味着你可能只有一次机会。
• 每个问题一个想法，绝不复合，下方带答案存根和 为什么这很重要 只在问题可能被误读的地方加一行。
• 明确允许回答「我不知道」——被标记的不确定是有用的；读起来像事实的自信猜测则不是。
• 一个收尾的兜底问题：有没有什么我们没问到、但应该知道的？

两件它刻意不是的事。它不是 branching ——问题是一个扁平的、分组列表，而不是一棵「答 A 就跳过 D 节」的树。而且它不是 multi-recipient ——一次运行为一个人生成一份文档。

常见问题

它会读取我的审问会话并从中提取问题吗？ 不是作为它自己的一步。技能没有摄取阶段：它问关于发送的问题，然后起草。让它在 追问审视 会话的关键在于你在 同一对话，所以这个 会话 已经在 context 而草稿可以从中取材。在一个全新会话中启动它，它对审问一无所知——当回答「你需要什么回复」时，你得自己重新提供主题。

缺失的答案并不都在同一个人那里。它能按接收者拆分吗？ 不。第一步要求 the 接收者，单数，整份文档的语气和背景都对准他。如果三个人各持有答案的三分之一，就运行三次，每人一次。在单份文档内按学科或角色路由问题，是有人提出过的请求；它不是已发布的样子。

问题之间是相互依赖的吗——它会根据先前的回答跳过部分章节吗？ 不。依赖式问题设计曾被探索过，但没有发布。输出是一份静态文档：主题分组、最重要优先、每个问题都可用。对它的反对是合理的—— model 在真实答案之前规划两三个以上的问题就是糟糕的规划，而分支式文档必须在每个答案之前规划全部问题。

如果接收者也不知道呢？ 文档告诉他们说出来。「我不知道」和部分答案被明确要求，被标记的不确定比猜测更值钱，因为模糊的回答和自信的错误答案一旦回到你的上下文里，看起来一模一样。

它会把它发送到任何地方吗——Slack、issue 追踪器、邮件？ 不。它会在当前目录写一个 Markdown 文件并告诉你路径。交付是你的活：把它粘贴进 ticket，丢进 Slack 线程、附到邮件里，或打开在共享屏幕上实时过一遍。人们手动把四种方式都接通过。

这不就是 /grill-me 以批处理模式？ 不，而这个区别值得坚持。 grill-me 已经在 rounds ——一次给出整个前沿，然后根据你的回答重新计算——所以「一次给我所有问题」的需求在那里被满足。 to-questionnaire 关于另一条轴：不是问题如何送达，而是答案在谁的脑子里。自己更快地回答它们，是 grill-me；从别人那里问出来，用的就是这个。

我不能不靠技能直接让智能体做这个吗？ 是的，而且在它存在之前就有很多人这样做—— OPEN_QUESTIONS.md 文件、发给客户的电子表格、每个未答问题一张「需要更多信息」的任务。技能带给你两样东西：审问永远不会漂移到主题本身上去，以及文档以非技术接收者真正能填写的形态产出。如果你已经有可用的内部格式，诚实地说，你不需要这个。

做到以下就算成功

• 它问接收者是谁、你需要什么回复，然后停止提问。问主题本身的问题，就是技能脱轨了。
• 你命名为「我需要什么回复」的每个条目，都能追溯到文件中的某个问题。
• 问题读起来瞄准 recipient 所知道的，而不是把你自己的开放问题逐字抄下来。
• 你可以把文件递给不在对话中的人，他们会知道为什么收到它、以及何时回复。
• 返回的答案是新一轮审问的可用输入，而不是一组全新问题。

在流程中的位置

to-questionnaire 是一个随时可调用的独立技能。它坐在你自身知识的边界上，那里下一步是另一个人而不是另一个技能——最常见于流程中途，当规划在某个不由你决定的事情上停滞时。

它的邻居是 grill-me，而两者在答案住在哪里上分工：审问开采你，问卷开采别人。返回的是原材料——喂进另一轮审问，或喂进 grill-with-docs or to-spec 如果工作要走向构建。当你不确定此刻该用哪个技能时， ask-matt 为你指路。