consensus-tech-research

共识驱动的技术调研

在 /grilling、/grill-me 或 /grill-with-docs 之后、/to-spec 之前使用。本技能依据已确认的决策完成技术选型，不重新开启设计访谈。

前置输入

研究前必须获得以下任一项：

• 已达成共识的约束摘要，以及待决定的技术问题。
• 对应的 CONTEXT.md、ADR 或其他 grilling 记录的路径。

将明确确认过的约束视为硬性条件。若待决问题、运行环境、部署环境或约束不完整，先只提一个聚焦的澄清问题；不得自行假设需求。

调研流程

1. 明确待决技术、硬性约束和比较维度。
2. 筛选 3 至 5 个符合硬性约束的候选项；候选项不满足任一硬性条件时，尽早淘汰并记录原因。
3. 优先使用当前的一手资料：官方文档、官方仓库、发布说明、包注册表、许可证文件和安全公告。可用时使用 anysearch 进行联网调研，并遵守其操作要求；必要时直接核验候选项的一手来源。
4. 无法获得当前证据时，才可使用模型内部知识，并明确标注“可能过时”；不得把它表述为已核验的现状。
5. 按已确认的维度比较候选项。默认维度为功能匹配度、兼容性、生态与维护活跃度、性能与运维成本、许可证与安全风险、团队学习成本。已有共识可替换或扩展这些维度。
6. 给出一个首选方案及其成立前提。若证据不足以负责任地选择，明确写出 暂不决策，并提出最小验证实验或需要补充的信息。

输出物

除非项目已有调研目录，否则写入：

docs/research/<topic>-tech-selection.md

报告使用以下结构：

# <主题> 技术选型

## 决策问题与约束
## 候选方案
## 对比分析
## 推荐结论
## 风险与验证计划
## 资料来源
## 供 to-spec 使用的决策摘要

每条资料来源必须包含 URL、标题、访问日期和所支撑的结论。对比必须解释实质性取舍和淘汰原因，不能只给分数。最后的“供 to-spec 使用的决策摘要”应可直接粘贴进规格，写明选定技术、理由、约束和未解决风险。

边界

• 不生成生产集成代码、脚手架，也不直接修改依赖。
• 若调研结果与已确认的产品或架构决策冲突，指出冲突并请求指示，不得擅自推翻。
• 没有当前且可引用的一手资料时，不得声称维护状态、漏洞状态或许可证状态为实时结论。