/to-questionnaire 技能
把待解答的问题变成一份由他人填写的文档。
Install this skill
npx skills@latest add mattpocock/skills --skill=to-questionnaireThen type /to-questionnaire in your coding agent.
- Source
- mattpocock/skills
本页内容
它的作用
to-questionnaire 把无法独自敲定的决策变成 questionnaire: a Markdown document you hand to the one person who holds what you're missing, for them to fill in async or for the two of you to work through in a meeting.
它就 send, never the subject. An interview about the topic is pointless, because not knowing the topic is why you're writing to someone else. So it asks the two things you can always answer (who this is going to, and what you need back from them) and aims every question in the document at the gap 两者之间。
何时使用
你通过输入 /to-questionnaire; the agent 不会自动调用它。
Reach for it when a decision is blocked on knowledge that lives in one other person's head: a client, a domain expert, an exec who owns the business rules, a colleague on a team you don't sit with. Which skill you want depends on where the answers are:
| 答案在…… | 何时使用 |
|---|---|
| 你自己未经磨砺的脑子 | grill-me |
| 代码库 | grill-with-docs |
| 另一个人的脑中 | to-questionnaire |
| Nobody's head yet, the question needs something to react to | prototype |
常见情况是 追问审视 session that stalls because some of the questions it raised aren't yours to answer. Run /to-questionnaire 在同一个对话中把那些问题离线处理,然后把答案带回来继续。
发送对象,而不是主题
审问只有两轮往来,然后就停。
- 它要给谁? Their role, their expertise, their relationship to you. This sets the tone and how much context the document has to carry. An outside client needs orienting; a teammate does not.
- 你需要什么回复? The concrete decisions or facts you can't resolve alone. This becomes the checklist for the finished document. Every item you name gets a question aimed at it.
Everything after that is drafting. The skill writes the file to to-questionnaire-<slug>.md 在当前目录中。没有配置、没有工作区、无需配置任何东西。
文档
The document is a 发现问卷, because you lack the context and the recipient has it. That sets its shape:
- A purpose line naming the decision that depends on it, and a short context section for a recipient who knows none of your background.
- 问题排序 most-important-first 并按主题标题分组,因为异步意味着你可能只有一次机会。
- 每个问题一个想法,绝不复合,下方带答案存根和 为什么这很重要 只在问题可能被误读的地方加一行。
- Explicit permission to answer "I don't know", because a flagged uncertainty is useful and a confident guess that reads like a fact is not.
- 一个收尾的兜底问题:有没有什么我们没问到、但应该知道的?
The document is deliberately not two things. It isn't branching. The questions are a flat, grouped list, not a tree that skips section D if you answered A. It isn't multi-recipient either. One run produces one document for one person.
常见问题
它会读取我的审问会话并从中提取问题吗? Not as a step of its own. The skill has no ingest phase. It asks about the send, then drafts. What makes it work after a 追问审视 会话的关键在于你在 同一对话,所以这个 会话 已经在 context and the drafting can draw on it. If you start it in a fresh session, it knows nothing about the grilling, and you supply the topic again yourself when you answer "what do you need back?".
缺失的答案并不都在同一个人那里。它能按接收者拆分吗? 不。第一步要求 the recipient, singular, and the skill pitches the tone and context of the whole document at them. If three people hold three parts of the answer, run it three times, once per person. People have asked for one document that routes questions by discipline or role, but that did not ship.
Are the questions dependent: does it skip sections based on earlier answers? No. The dependent-question design was explored and did not ship. The output is a static document: themed groups, most-important-first, every question live. The objection to it is fair. A model that plans more than two or three questions ahead of a real answer plans badly, and a branching document has to plan all of them ahead of every answer.
如果接收者也不知道呢? The document tells them to say so. It explicitly asks for "I don't know" and partial answers. A flagged uncertainty is worth more than a guess, because a vague answer and a confidently wrong one look identical once they're back in your context.
Does it send it anywhere (Slack, an issue tracker, email)? 不。它会在当前目录写一个 Markdown 文件并告诉你路径。交付是你的活:把它粘贴进 ticket, drop it in a Slack thread, attach it to an email, or open it on a shared screen and work through it live. People have done all four by hand.
这不就是 /grill-me 以批处理模式?
No. grill-me 已经在 rounds. It asks the whole frontier of open questions at once, then recomputes it from your answers, so it already meets the "give me all the questions at once" need. to-questionnaire differs on another axis. It is about whose head the answers are in, not how the questions are delivered. To answer them yourself faster, use grill-me. To get them out of someone else, use this.
我不能不靠技能直接让智能体做这个吗?
Yes, and plenty of people did before it existed: OPEN_QUESTIONS.md files, spreadsheets sent to clients, a "needs more info" ticket per unanswered question. The skill buys you two things: the interview never drifts onto the subject, and the document comes out in a shape a non-technical recipient can fill in. If you already have a house format that works, you don't need this.
做到以下就算成功
- It asks about the recipient and about what you need back, then stops asking. If it asks about the subject itself, the skill has gone wrong.
- 你命名为「我需要什么回复」的每个条目,都能追溯到文件中的某个问题。
- 问题读起来瞄准 recipient 所知道的,而不是把你自己的开放问题逐字抄下来。
- 你可以把文件递给不在对话中的人,他们会知道为什么收到它、以及何时回复。
- 返回的答案是新一轮审问的可用输入,而不是一组全新问题。
在流程中的位置
to-questionnaire is a reach-for-it-anytime standalone. You use it where your own knowledge ends and the next move is to ask another person, not to run another skill. That is most often mid-flow, when planning has stalled on something that isn't yours to decide.
它的邻居是 grill-me, and the two differ on where the answers live. Grilling gets the answers from you; a questionnaire gets them from someone else. Feed what comes back into another grilling round, or into grill-with-docs or to-spec 如果工作要走向构建。当你不确定此刻该用哪个技能时, ask-matt 为你指路。
Skill actions
npx skills@latest add mattpocock/skillsInstalls the whole set. Then type /to-questionnaire in your coding agent.