决策问卷
把无法回答的决策变成一份问卷文档。
技能元数据
| 来源 | 可选 — 使用 hermes skills install official/productivity/decision-questionnaire 安装 |
| 路径 | optional-skills/productivity\decision-questionnaire |
| 版本 | 1.0.0 |
| 作者 | Matt Pocock (mattpocock/skills, to-questionnaire) + Hermes Agent |
| 许可证 | MIT |
| 平台 | linux, macos, windows |
| 标签 | questionnaire, decision, async, stakeholder, discovery, communication |
| 相关技能 | meeting-action-items, document-to-action-items |
参考：完整的 SKILL.md
信息
以下是 Hermes 在该技能被触发时加载的完整技能定义。这就是技能激活后，智能体看到的指令内容。
决策问卷
把用户无法独自回答的事情变成一份问卷：一份 Markdown 文档，用户可以交给某一个人异步填写，或在会议中一起填写。接收方掌握着用户所缺少的知识；问卷的作用就是把它撬出来。
移植自 mattpocock/skills 采用 MIT 许可证的 to-questionnaire 技能。
何时使用
- 某项决策卡在他人掌握的事实或判断上（领域 专家、利益相关方、供应商联系人、运维）
- 用户说“我得就这件事问问 X”，或一直因等待他人 输入而推迟决策
- 为一场必须拿到具体答复的会议做准备
不要在答案可从环境中发现时使用（代码库、 文档、网络）——先自己找。
核心原则：访谈“这次派发”，而非主题本身
用户无法回答主题层面的问题（这正是重点），但 他们总能回答关于“这次派发”的问题。只就此进行访谈，分两轮简短交流：
- 要发给谁？ 角色、专长、与用户的关系。这 决定问卷的语气以及需要承载多少上下文。当你 知道接收方是谁，以及他们掌握哪些用户不具备的知识时，即完成。
- 你需要拿回什么？ 用户无法独自解决的具体 决策或事实。当你拿到一份明确清单，列明用户 结束时必须能够去做或去决定的事项时，即完成。
然后撰写问卷：围绕接收方所知与用户所需之间的差距，
依据以下结构起草问题。写入当前目录下的
decision-questionnaire-<slug>.md（slug 取自主题），并报告绝对路径。当你
完成且第 2 步中的每一项都有问题覆盖时，文件即完成。
文档结构
将其定位为一份探索型问卷：用户缺少上下文，接收方
掌握它。问题按重要程度排列，最重要的在前（异步意味着
你可能只有一次机会）。一旦问题超过几个，就用 ## 标题按主题分组。
模板：
# <问卷标题>
**目的：** 这份问卷为何存在，以及背后依托的决策。
**发件人：** <用户> · **收件人：** <接收方> ·
**你的回答将如何使用：** <它们会流向哪里>
## 背景
一段话，帮助并不了解用户所思所想的接收方快速入门。足以
答得妥当，而非一整页。
## 如何作答
截止时间和大致的投入量。部分作答和“我不知道”也有用：
任何你不确定的地方都请标出，而不是跳过。
## <主题标题>
### <一个问题——单一想法，绝不要复合问题>
_为何重要：<一行，只用在问题可能被误解或
招致敷衍回答的地方>。_
>
## 还有其他补充吗？
一个收尾的兜底问题：有没有我们没问到但应该知道的事情？
每个问题下方直接跟一个答案占位符（>）。
陷阱
- 就主题本身盘问用户。 他们回答不了——这正是 文档存在的原因。只访谈“这次派发”。
- 复合问题。 每个问题只问一个想法；拆分带有“和/或”的问题。
- 埋没关键问题。 最重要的在前；异步 接收方会逐渐失去关注。
- 背景信息堆砌。 一段用于定位的段落，而非整个来龙去脉。
- 有歧义问题上省略“为何重要”一行。 它能把敷衍的回答 变成有用的回答——但不要加在 已经毫无歧义的问题上。
验证
- 在起草前，经两轮交流已捕捉接收方的角色/知识和 所需成果
- 第 2 步中的每一项都至少被一个问题覆盖
- 问题为单一想法、最重要的在前、带有答案占位符
- 文件已写入，并已向用户报告绝对路径