Analyze Research Skill
子类型标识:
analyze.research
触发条件
用户要求调研、评估或比较某技术方案,主要目标是获得信息和建议(而非直接实施)。
| 场景 | 示例 |
|---|---|
| 技术选型 | "对比 Redis/Memcached,推荐缓存方案" |
| 可行性评估 | "评估引入 GraphQL 的成本和收益" |
| 概念验证 | "验证 WebSocket 在我们架构下是否可行" |
| 依赖调研 | "调研 @org/lib 是否满足需求" |
| 根因调查 | "找出导致内存持续增长的根因" |
| 隐性推荐/取舍 | 用户问"是否应该""哪个更好""有没有更好建议",且结论会影响技术路线、产品/项目选择、时间/金钱投入或长期维护成本 |
⛔ 只读原则
调研过程中禁止修改任何项目源码文件。若结论需要代码变更,在报告中说明并建议切换到 dev/fix 工作流。
执行流程
| 步骤 | 动作 |
|---|---|
| 1 | 明确调研问题(一句话核心问题) |
| 2 | 确认调研范围(深度 + 技术栈约束) |
| 3 | 收集信息(profile + 源码 + 同类产品 / 项目 / 模块对比 + 依赖文档)并建立关联文件集合 |
| 4 | 分析评估(按调研类型,至少 3 轮) |
| 5 | 收敛前再跑一次 CRS,确认关联文件集合无遗漏 |
| 6 | PCV(收敛后汇总验证,含合理性 + 可实施性 + 收益) |
| 7 | 输出明确结论(禁止模糊结论) |
| 8 | 输出调研报告 |
统一联查矩阵(research 最小动作)
research默认执行 analyze-lite 联查:关键词提取 → 关联文件集合 → 收敛前再跑一次 CRS- 命中控制面、多真相源、模板-示例-校验链或单轮发现 ≥5 条 / 出现 🔴 问题时,应主动建议升级到
audit ComparativeResearchGate命中时,先比较同类产品 / 项目 / 本仓库相似模块 / 已有设计;若属于纯解释、低风险本地事实或用户明确要求快速答复,记录N/A + skipReason,不得把普通问答默认升级成重调研- 输入来自审查报告、AI review finding、audit issue 或代码评审发现时,必须执行
ReviewFindingIntakeGate:先把报告当线索补本地证据,再区分 must-fix、设计如此、用户决策、文档/实现漂移、测试覆盖缺口和未复现项
各类型输出格式
技术选型:
text推荐:[方案名] 理由:[2~3句话,聚焦关键差异] 注意事项:[风险/限制]
可行性评估:
text结论:[可行 / 有条件可行 / 不可行] 前置条件:[无则填"无"] 成本估算:[工程量/依赖变更/测试] 风险点:[主要风险] 备选方案:[若不可行]
依赖/兼容性评估:
text业务源码平滑性:[当前源码/调用方/配置/公开契约是否需适配] 依赖层落地条件:[版本 / Node 或 peer dependency / lockfile / CI runner / 发布与文档要求] 纯依赖层零附加动作:[是 / 否 / N/A;给出证据] 内部共享库评估:[是否应修共享库 + 消费项目升级;若否说明理由]
根因调查:
text现象:[观察到的问题] 根因链路:[现象 ← 直接原因 ← 根本原因] 影响范围:[受影响模块/接口/数据] 修复建议:[优先级排序的修复步骤] 预防措施:[避免复发的改进点]
输出
报告:reports/analysis/ 目录,遵循 report/SKILL.md 命名规则。


