决策问卷 · decision-questionnaire

二次开发：本技能改编自 mattpocock/skills 的 productivity/to-questionnaire（MIT © 2026 Matt Pocock），在保留其核心方法论基础上，升级为「提示词 + 可执行 CLI」双形态。署名见本目录 NOTICE.md 与仓库 THIRD_PARTY_NOTICES.md。

这个技能做什么

把"用户自己一个人拍不了板、必须向某个特定的人确认"的决策，变成一份可异步填写的 Markdown 问卷：交给对方后等其书面回复即可，也可以约半小时会议当面填。

核心原则一句话：拷问发送者，不拷问被访者。

• 访谈环节只拷问用户本人（发送者）：这份问卷发给谁、用户需要从对方那里拿回什么——这些问题用户永远答得上。
• 问卷正文里的每一道题，都只瞄准"收件人知道、而用户不知道"的信息缺口；绝不问对方答不了、或用户自己本来就知道的事。

典型适用场景（中文职场高频）：

• 跨部门信息收集：向兄弟部门确认接口、排期、资源口径；
• 需求调研：向业务方 / 用户代表确认使用场景、优先级、约束条件；
• 访谈提纲：约专家、老员工、离职同事沟通前，先把问题结构化；
• 供应商问询：比价、能力范围、交付条件的书面问询；
• 汇报前材料核实：向上汇报前，向相关方核对数据与事实口径。

输入要求

• 必填：用户自己说清楚三件事（这也是 CLI 输入文件应包含的内容）：
  1. 收件人是谁：对方的岗位 / 专业领域 / 与用户的关系（上级、平级协作方、供应商还是客户）；
  2. 用户需要拿回什么：具体的决策或事实清单——用户一个人定不下来、必须靠对方答复才能拍板的那些事；
  3. 背景素材：这件事的来龙去脉、已有的初步判断、时间压力。
• 可选：截止时间、预计填写耗时、希望对方回复的形式。
• 信息不足时：先向用户追问补全（尤其是"收件人掌握什么用户不知道的信息"），不要凭空出题；实在补不上的地方标注"（待用户确认）"。

输出结构（模板见 scripts/templates/decision-questionnaire.template.md）

一份完整问卷，自上而下：

1. 标题：# 决策问卷 · {问卷主题}。
2. 问卷用途与收发信息：问卷用途（Purpose——这份问卷为什么存在、背后要支撑哪个决策）、发件人 / 收件人、答复用途（回收的答复将被用在哪里）。
3. 背景（Context）：一段话，把没参与用户脑内过程的收件人拉回现场——够答好题即可，不写成一页报告。
4. 答题说明（How to answer）：截止时间与大致耗时；明确告知"答不全没关系、不知道就标注不知道，不要空着跳过"。
5. 按主题分组的问题：用 ## 按主题分组；最重要的排最前（异步填写可能只填一轮）；每题只问一个意图，绝不复合提问；每题正文下方留答题空位（> 引用块）；容易被误解或容易收到敷衍答案的题，加一行"为什么问这个"（why-this-matters）。
6. 末尾开放题（还有什么遗漏）：还有什么我们没问到、但您觉得我们应当知道的？

工作流程

1. 只访谈用户本人（第一步）：一次追问里问清收件人的角色、专长、与用户的关系——这决定问卷的语气和背景要写多厚。停在：你知道问卷发给谁、对方手里有什么用户没有的信息。
2. 问清要拿回什么（第二步）：一次追问里问清用户必须拿到的具体决策 / 事实清单。停在：用户拿着这份问卷的答复，就能直接去拍板或写汇报。
3. 针对 gap 出题（第三步）：对照前两步，只把"收件人知道而用户不知道"的点写成题；按模板组装，最重要排最前，写成文件并报告路径。
4. 复核覆盖度：第二步用户列的每一项，必须至少被一道题覆盖；缺了就补题，不许漏。

质量规则（必须遵守）

• 拷问发送者、不拷问被访者：问卷里绝不出现"你们部门当时为什么这么定""你们是怎么考虑的"这类需要对方拷问自己立场的题；只问事实与判断，不问态度与责任。
• 只问对方能答的事：每道题先过一遍——这个信息在收件人的岗位职责 / 经历 / 数据范围内吗？不在就删掉或改写。
• 一题一意图：禁止复合问句（"请说明排期和预算"要拆成两题）。
• 最重要排最前：异步填写可能只有一轮，关键决策题放最前。
• 容错提示必须写：答题说明里必须出现"不知道也请标注、不要空着跳过"。
• 答题空位必留：每道题正文下方留 > 引用块作答区。
• 必要时才写 why-this-matters：只在题目容易被误解、或容易收到一句敷衍答案时加一行，不堆废话。
• 背景一段即可：收件人不是来读报告的，一段话给足上下文。
• 中文公文式措辞：占位符与语气用中文职场书面语（"烦请""敬请于……前反馈""供决策参考"），不直译英文模板腔。

边界与异常处理

• 收件人是用户上级或客户 → 语气改为请求式，背景写更完整，why-this-matters 一律省略（避免显得在考对方）。
• 收件人是平级协作方 → 可保留轻量 why-this-matters，说明这道题支撑哪个决策。
• 用户说不清"要拿回什么" → 先帮用户列候选清单让其勾选，不直接写问卷。
• 收件人可能根本不知道答案 → 该题注明"如不掌握，烦请直接转介相关同事"，并在末尾开放题收集转介线索。
• 问题超过 8 道 → 必须按主题用 ## 分组，不要平铺一长串。
• 中英混杂场景（如涉外供应商）→ 保留英文专有名词，题干用中文。

与脚本配合

• 批量 / 命令行场景：scripts/draft_decision_questionnaire.py（纯标准库，一条命令跑通）；输入为用户访谈要点文本（收件人是谁 / 需要拿回什么 / 背景），输出为成稿问卷 Markdown。
• 自定义模板：复制 scripts/templates/decision-questionnaire.template.md 修改后使用。