技术选型（Tech Evaluation）
核心思路：选型的核心不是"哪个更好"，而是"在我们的场景下哪个更合适"。没有最好的技术，只有最合适的技术。
一、用途 用于在多个候选技术方案之间做出有依据的决策。与 deep-research 的区别在于：deep-research 是广度调研（搞清楚一件事），tech-evaluation 是聚焦决策（A 还是 B，选哪个，给结论）。
触发词：选型、选哪个、A 还是 B 等。
二、主要能力
- 定义选型问题：通过 AskUserQuestion 明确要解决的问题、候选方案、硬性约束（许可证、语言、兼容性）、优先维度（性能／生态／学习成本／成本）和决策时间。
- 快速筛选：用硬性约束做第一轮筛选，输出候选方案筛选表，标记进入评估或排除。
- 快速判断路径：若筛选后只剩 1-2 个候选且差异明显，直接给出推荐加理由，不走完整评估，记录决策到 spec 文档即可；若有 2-3 个势均力敌的候选，进入完整评估。
- 多维度评估：构建评估矩阵，常见维度与权重示例为功能匹配度 30%、性能 25%、生态与社区 20%、学习成本 15%、运维成本 10%。权重确定方式：用户明确说了优先级就直接用，没说则给出建议权重让用户确认。
- 逐维度评估：功能匹配度用需求清单逐项检查，性能找 benchmark 或自跑 PoC，生态与社区看 GitHub stars／issues 响应速度、npm 周下载量、Stack Overflow 问题数，学习成本看文档质量与 API 设计，运维成本看部署方式、配置复杂度与升级历史。
- PoC 验证（可选但推荐）：对关键维度写代码验证，对比代码量和复杂度、实际性能数据、遇到的坑。PoC 不需要做完整功能，只验证最不确定的维度。
- 综合评分与决策：汇总各维度加权总分，给出推荐方案、核心理由、取舍说明和风险提示。
- 输出选型报告：写入 spec 文档，至少包含背景与动机、候选方案、评估过程（维度、权重、数据来源）、PoC 结果、决策与取舍。
三、使用方式 按步骤推进：第一步定义选型问题，第二步快速筛选，第三步多维度评估（含可选的 PoC 验证），第四步综合评分与决策，第五步输出选型报告。报告中可调用 writing skill 的技术文档模式。
四、选型准则 场景优先；数据说话，每个评分都要有事实依据；验证不确定性，最不确定的维度用 PoC 验证；考虑团队，学习成本是真实成本；留退路，优先选不锁定的方案；不过度评估，2 个候选差异明显就直接选。
五、与其他 skill 的关系
- task-start（方案阶段遇到选型）→ tech-evaluation（评估决策）
- deep-research（需要广度调研时）← tech-evaluation 按需调用
- tech-evaluation → writing（输出选型报告到 spec） 区别：tech-evaluation 必须给结论（"选 A，因为 XYZ"）；deep-research 不一定给结论（"目前市场格局是这样，趋势是那样"）。选型前如果对候选方案不够了解，可以先用 deep-research 调研，再用 tech-evaluation 决策。
六、限制 上述评估维度权重为示例默认值，实际权重需由用户确认。PoC 与报告的具体产出依赖实际项目场景，资料中未提供具体费用、价格或平台支持信息。