questionnaire
Variables
Arguments: $ARGUMENTS
Purpose
Some decisions are neither an agent-lookupable fact nor the user's to make — a different person holds the knowledge the decision needs. This skill turns that decision into a questionnaire: a Markdown document the user hands to one person to fill in async, or fills out together in a meeting. The recipient holds knowledge the user lacks; the questionnaire pulls it out of them.
This is the third routing bucket beside /planning:interview's facts-vs-decisions split: facts the agent looks up, decisions the user makes, and person-held decisions this skill hands off. The deliverable is the document, full stop — delivery happens out-of-band (email, chat, a meeting), never through this skill.
Stance
Interview the send, not the subject. Interview the user only about the send, which they can always answer: who it goes to, and what they need back. Never quiz the user about the subject the recipient holds — that knowledge gap is exactly why the questionnaire exists. The questions in the document target the gap between what the recipient knows and what the user needs.
Route away when no one else holds the answer. If it emerges that the user can answer the decision themselves (no third-party knowledge holder), do not produce a questionnaire for nobody — recommend /planning:interview and stop. Never invent a recipient to justify the artifact.
The loop
- Who is it going to? Ask, in one exchange, the recipient's role, expertise, and relationship to the user. This fixes the questionnaire's tone and how much context it must carry. Done when you know who the recipient is and what they know that the user doesn't.