to-questionnaire把卡在别人脑子里的决策加工成一份可交付的问卷文档【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills导读to-questionnaire是 skills13/skills 仓库 productivity 目录下的一个用户主动调用的技能skill当一项决策被卡在某个特定的人的脑子里客户、领域专家、掌握业务规则的负责人、你不在同一团队的同事而你无法独自拍板时它把你脑中悬而未决的问题转化为一份Markdown 问卷文档——交给那位唯一能解答的人异步填写或两人在会议上逐条过一遍。读完本文你将掌握它的触发方式与适用边界、审问发送对象而非主题的核心方法论、两轮提问的完整流程、问卷文档的标准化结构含可直接套用的模板以及它与其他 grilling 系技能的边界划分。它做什么把别人的知识变成可交付的问卷to-questionnaire的核心动作可以用一句话概括把一个你独自无法拍板的决策变成一份问卷文档。这份文档交给你缺失信息的那唯一一位接收者由对方异步填写或者由你们双方在会议上共同过一遍。它的定义与入口在 SKILL.md 中写得非常明确Turn something the user cant answer alone into aquestionnaire: a Markdown document they hand to one person to fill in async, or fill out together over a meeting.这里的关键区分是技能不审问主题subject只审问发送send。访谈你不会围绕话题本身展开——因为你之所以写信给别人正是因为你不懂这个主题。所以它只问两件你总能回答的事这封信发给谁who this is going to你需要从对方那里拿回什么what you need back from them。文档中的每一道问题都精确瞄准这两者之间的空白gap即对方知道而你不知道的那部分知识。见 docs/productivity/to-questionnaire.md 开篇。何时使用答案到底在谁的脑子里to-questionnaire的触发方式为用户手动输入/to-questionnaire模型不会自行调用它。这在仓库中有双重佐证技能头部声明了disable-model-invocation: true见 SKILL.md对应的 Codex 配置 agents/openai.yaml 中设置了policy.allow_implicit_invocation: false即禁止隐式调用。两种配置表达的是同一个意图这是一个伸手去拿reach-for-it的技能不是一个自动触发的技能。产品目录的 README.md 也把to-questionnaire归入 User-invoked用户调用一类与grill-me、handoff、teach、wait-what并列。那么什么时候该伸手去拿它原文档给出的判据是当一项决策被阻塞在另一个人的头脑里。具体选哪个技能取决于答案实际存放在哪里答案存放在…应该使用你自己的脑子里但还没打磨锋利grill-me代码库里grill-with-docs另一个人的脑子里to-questionnaire还没人知道问题需要一个东西来回应prototype最常见的真实场景是一场 grilling 会话进行到一半卡住了。你与 Agent 的拷问过程中浮出了一些问题但它们并不归你回答——它们属于某位不在场的人。此时不需要开新会话直接在当前会话中运行/to-questionnaire把这些属于别人的问题离线带走等对方答完再带回来继续原来的 grilling。这正是它设计上无摄入阶段no ingest phase的价值所在它不读你的 grilling 记录而是依赖同一会话上下文来起草文档。只审问发送不审问主题两轮提问原文档强调访谈只有两轮交换问完就停发给谁需要问清对方的角色、专长、与你发送方的关系。这三个信息决定了整份文档的语气和需要携带多少背景上下文外部客户需要充分的背景铺垫同组同事则不需要。需要拿回什么具体列出你无法独自解决、必须从对方那里得到的决策或事实。这份清单会成为成稿文档的验收清单你列出的每一项都会对应文档中的一道问题。在 SKILL.md 中这两轮被编码为技能执行步骤的前两步并明确给出了每一步的完成判定Who is it going to?一轮交换内问清接收者的角色、专长、与用户的关系。当你知道接收者是谁、他们知道什么用户不知道的时即告完成。What do you need back?一轮交换内问清用户无法独自解决、需要从此人身上拿到的具体决策或事实。当你拿到一份用户必须带着离开的能力或可做决策的具体清单时即告完成。Write the questionnaire.依据前两步瞄准空白起草问题写入当前目录下的to-questionnaire-slug.mdslug 取自主题并回报文件路径。当文件存在、且第 2 步中用户列出的每一项都被某道问题覆盖时即告完成。两轮之后剩下的全是起草工作。产物落在当前目录的to-questionnaire-slug.md。没有安装步骤、没有工作区、没有任何需要配置的东西——这是它与grill-with-docs会写CONTEXT.md和 ADR 到仓库最直接的区别。产出的文档长什么样discovery questionnaire 结构生成出的文档被框定为一份发现型问卷discovery questionnaire你没有上下文而接收者持有它。这一框架决定了它的形态原文档列出了五个结构要点一行目的说明点明这份问卷所承载的决策随后是一小段上下文context服务于一位从未进过你脑子的接收者。问题按**最重要优先most-important-first**排序并按主题分组到带标题的段落之下——因为异步意味着你可能只有一次让对方回答的机会。每题只承载一个想法绝不复合题目下方留有作答区answer stub只有当问题可能被误读时才附加一行为什么这个问题重要why this matters。明确允许对方回答我不知道被标记出来的不确定性是有价值的而一个读起来像事实的自信猜测则不是。结尾有一个兜底问题catch-all还有什么我们没问到、但你应该告诉我们的SKILL.md 里还给出了可直接套用的完整模板逐字继承如下# Questionnaire title **Purpose:** why this questionnaire exists and the decision riding on it. **From:** the user, **To:** the recipient, **How your answers will be used:** where they go ## Context One paragraph orienting a recipient who wasnt in the users head. Enough to answer well, not a page. ## How to answer Deadline and rough effort. Partial answers and I dont know are useful: flag anything youre unsure of rather than skipping it. ## Theme heading One ## section per theme. Under each, its questions, most-important-first. Every question is one idea, never compound, with an answer stub directly beneath, and a one-line _why this matters_ only where the question could be misread or invite a throwaway answer. ### What load is the system expected to handle at launch? _Why this matters: it decides whether we provision for burst traffic now or defer it._ ## Anything else? A closing catch-all: anything we didnt ask that we should know?注意模板中的两个细节一是## How to answer段落会写清截止时间和大致的投入成本并再次强调部分回答和我不知道都是有用的二是示例题目展示了一条_why this matters_注解的写法——它只用在题目可能被误读、或可能引来敷衍回答的地方并不是每题必备。它刻意不是什么两个设计边界原文档明确划出了两个刻意不做的边界它不做分支branching问题是一份扁平的、分组的有序列表而不是一棵如果你回答了 A 就跳过 D 节的决策树。它不是多接收者multi-recipient运行一次只产生一份文档、给一个人。语气和上下文都是针对那一个人调校的。如果三个不同的人握着答案的三个部分就运行三次一人一份。常见问题与边界划分原文档以 FAQ 形式回答了几个高频疑问这些正是使用者最容易踩坑的地方它会读取我的 grilling 会话并从中抽取问题吗不会作为独立步骤。技能没有摄入阶段ingest phase它只问发送然后起草。它之所以能在 grilling 之后正常工作是因为你在同一个会话里运行它——会话上下文已经在模型上下文中起草可以取材于它。如果开一个新会话运行它对 grilling 一无所知你就得自己在回答需要拿回什么时重新提供主题。缺失的答案不都在同一个人手里能按接收者拆分吗不能。第一步问的是单数意义上的那位接收者整份文档的语气和上下文都以他为准。三人各持一部分答案就运行三次。问题之间有依赖吗会基于前面的回答跳过某些段落吗不会。依赖式问题的设计曾被探索过但没有交付。产出是一份静态文档按主题分组、最重要优先、每题都在。反对依赖式设计的理由很实在模型很难在真实答案之前为两道三道以上的问题做规划而分支式文档必须在每个答案之前规划全部问题。如果接收者也不知道怎么办文档直接告诉对方说出来。我不知道和部分答案是被明确请求的标记出的不确定性比猜测更有价值因为模糊的回答和自信的错误答案一旦回到你的上下文里看起来一模一样。它会发送到任何地方吗Slack、issue tracker、邮件不会。它只在当前目录写一个 Markdown 文件并告诉你路径。交付是使用者自己的事粘贴进 ticket、丢进 Slack 线程、附在邮件里、或者共享屏幕现场逐条过。这四种方式都有人手动接通过。这不就是/grill-me的批处理模式吗不是而且这个区别值得分清。grill-me本身就是**按轮次rounds**提问的一次把整个前沿frontier全部抛出再根据你的回答重算——一次性给我所有问题这个需求在那边已经满足了。to-questionnaire关注的是另一个轴不是问题怎么交付而是答案在谁的脑子里。更快地自己作答是grill-me把答案从别人脑子里取出来是这个技能。我不能直接让 Agent 做这件事非要一个 skill 吗可以而且它出现之前很多人就是这么干的OPEN_QUESTIONS.md文件、发给客户的电子表格、每个未答问题一张需要更多信息的 ticket。这个技能买来两样东西访谈永远不会漂移到主题上产出的文档形状是非技术接收者真的能填的。如果你已经有一套行之有效的自家格式诚实的答案是你不需要这个。为什么不支持分支支持分支的代价在前述 FAQ 中已说明模型在真实答案出现之前只能可靠地规划两到三个问题而分支文档必须为每一个答案预先规划全部后续路径。静态分组 最重要优先 每题必答是对异步可能只有一次作答机会这一约束的诚实回应。判断它是否工作正常验收清单原文档给出了一套可操作的验收标准可用来判断一次/to-questionnaire会话是否跑对了它问过接收者、问过你需要拿回什么然后就停止提问。如果它开始追问主题本身说明技能已经跑偏。你命名为需要拿回什么的每一项都能在文件中溯源到对应的问题。问题的读感是瞄准接收者所知的而不是你个人未决问题的一字不差誊抄。你可以把这份文件交给一位没参加过对话的人对方能知道为什么收到它、以及何时该回复。收回的答案能作为新一轮 grilling 的可消化输入而不是又冒出一批新问题。它在整个技能体系中的位置to-questionnaire是一个随时可伸手的独立技能reach-for-it-anytime standalone。它坐在你自己知识的边界上在这个位置下一步是另一个人而不是另一个技能——最常见的触发时机是在流程中途当规划停滞在某个不归你决定的事情上。原文档给出了它与邻接技能的划分它的邻居是grill-me两者以答案在哪里为界——grilling 挖掘你自己questionnaire 挖掘别人。拿回来的答案是原材料可以喂进下一轮 grilling也可以在其后衔接 grill-with-docs在代码库中继续打磨并落盘CONTEXT.md与 ADR或 to-spec把对话综合成规格——当工作要走向落地构建时。当你拿不准该用哪个技能时ask-matt负责给你路由。从仓库的实际文件结构看这一定位是自洽的to-questionnaire是 skills/productivity 目录下七个用户主动调用技能之一与grill-me、handoff、teach、wait-what同级而承载拷问机制的grilling原语则被标记为 model-invoked作为grill-me、grill-with-docs等技能共用的底层访谈循环见 grilling 的 SKILL.md。to-questionnaire站在访谈循环之外它不复用 grilling 的轮次机制而是用两轮提问 起草的轻量流程专门解决答案在别人脑子里这一种特定的停滞。【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考