← ClaudeAtlas

to-questionnairelisted

Turn a decision you cannot answer alone into a questionnaire for one other person to fill in — async, or together in a meeting. Use when the answer is a fact somebody else holds, and neither the code, the docs nor your own judgement can settle it.
konstantinos-malavazos/claude-code-playbook · ★ 2 · AI & Automation · score 71
Install: claude install-skill konstantinos-malavazos/claude-code-playbook
# To questionnaire — pull the answer out of the person who has it The fourth kind of open question. `research` reads documents, `grilling` asks the human in the room, `task` gets someone to *do* something. This one asks someone what they **know**. > Prior art: Matt Pocock's `to-questionnaire` skill (MIT). Re-derivation: same three steps > and document shape, with the repo's own file convention instead of a fixed path. ## Grill the send, not the subject Interview the user about the **send** only — who it goes to, and what they need back. They can always answer that. They cannot answer the subject. That is why there is a questionnaire. 1. **Who is it going to?** One exchange: the recipient's role, what they know, their relationship to the user. This sets the tone and how much context the document carries. 2. **What do you need back?** One exchange: the decisions or facts blocked on this person. Done when you have a concrete list of what the user must walk away able to decide. 3. **Write it**, aimed at the gap between the two. **Every question targets the gap.** A question the user could answer themselves is padding, and padding is what makes a recipient skim. ## Where the file goes **Match whatever convention the repo already uses for notes**, the same rule [`research`](../research/SKILL.md) follows. If there is none, put it beside the ticket's handoffs. Name the path in your report either way. A questionnaire nobody can find was not written. ## The document Ord