/analyze-research

name: analyze-research
description: 技术调研子类型规范 — 技术选型/可行性评估/根因调查，只读工作流

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、设计如此、用户决策、文档/实现漂移、测试覆盖缺口和未复现项

各类型输出格式

**技术选型**：

推荐：[方案名]
理由：[2~3句话，聚焦关键差异]
注意事项：[风险/限制]

**可行性评估**：

结论：[可行 / 有条件可行 / 不可行]
前置条件：[无则填"无"]
成本估算：[工程量/依赖变更/测试]
风险点：[主要风险]
备选方案：[若不可行]

**依赖/兼容性评估**：

业务源码平滑性：[当前源码/调用方/配置/公开契约是否需适配]
依赖层落地条件：[版本 / Node 或 peer dependency / lockfile / CI runner / 发布与文档要求]
纯依赖层零附加动作：[是 / 否 / N/A；给出证据]
内部共享库评估：[是否应修共享库 + 消费项目升级；若否说明理由]

**根因调查**：

现象：[观察到的问题]
根因链路：[现象 ← 直接原因 ← 根本原因]
影响范围：[受影响模块/接口/数据]
修复建议：[优先级排序的修复步骤]
预防措施：[避免复发的改进点]

输出

报告：`reports/analysis/` 目录，遵循 `report/SKILL.md` 命名规则。