| name | research |
| description | 调研工作流引擎。自动判断调研级别（L1/L2/L3）和场景（W1-W6），按工作流模板执行。L1 快查在主线程完成，L2/L3 用子代理执行。当任务涉及技术选型、方案对比、可行性评估、寻找现有工具或最佳实践、信息查询（新版本/新功能/现状调研）时自动触发。用户可通过 /research 命令确定性激活。 |
调研工作流引擎
触发后自动声明 [MODE: RESEARCH]。
Step 1: 去重检查（L2/L3 必做）
L1 快查跳过此步。L2/L3 调研启动前：
- 读项目
docs/research/INDEX.md（如存在）
- 读全局
~/.claude/memory-bank/research/INDEX.md
- Grep 关键词匹配已有调研
- 找到相关 → 提示用户：复用（直接引用）/ 刷新（以旧报告为基础更新）/ 忽略（全新调研）
Step 2: 分级判断
根据 contexts/research.md 的分级规则判断 L1/L2/L3。
Step 3: 场景识别
根据 contexts/research.md 的场景→工作流表选择 W1-W6。
组合调研时识别多个工作流，每个分配给一个子代理。
Step 4: 需求澄清（按需）
如存在不确定性（功能边界、技术路线、偏好），用 AskUserQuestion 澄清（最多 2-3 个问题）。
L1 和需求已清晰时跳过。
Step 5: 执行声明
执行前向用户展示当前配置：
[MODE: RESEARCH] 调研启动
- 级别: L{1|2|3}
- 工作流: W{N} {工作流名称}
- 验证深度: {🔴|🟡|🟢}
- 时效性: {🔥|📅|📚}
- 工具: {将使用的主要工具列表}
- 执行方式: {主线程快查 | 单个子代理 | N 个并行子代理}
L1 快查可简化为一行：[RESEARCH L1] 主线程快查，使用 {工具}
Step 6: 执行
L1: 主线程快查
Read/Grep/Glob → 直接回答。无报告、无 PRD。
L2: 单个子代理
读取工作流模板文件后，启动子代理：
# 先读工作流模板
workflow = Read("~/.claude/skills/research/workflows/{W1|W2|W3|W4|W5|W6}.md")
Agent(
subagent_type: "Researcher",
description: "调研 {任务简述}",
prompt: """
按以下工作流模板执行调研：
{workflow 内容}
调研问题：{详细描述}
验证深度：{🔴/🟡/🟢}
时效性：{🔥/📅/📚}
工具：按你内置的搜索工具优先级表执行（researcher.md）。
GitHub 元数据（stars/last commit/语言）已由主线程用 gh CLI 获取，见上方 context。
质量要求：
- 每个关键声明附来源 URL（声明-来源配对）
- 区分"已验证事实"和"推测"，推测显式标注
- 报告末尾必须有"## 参考来源"章节，列出所有引用的 URL
输出要求：
1. 筛选后的结果摘要（保留重要细节，去掉噪音和重复）
2. 写报告到 {存储路径}/YYYY-MM-DD-{主题}.md
3. 更新对应的 INDEX.md（追加一行）
4. 返回：摘要 + Top 3 关键来源 URL（附对应声明）+ 文件路径 + 不确定项
""",
run_in_background: true
)
L3: 多个并行子代理
识别子领域/工作流组合后，同一个 message 中启动多个 Agent：
Agent("Researcher", "按 W1 方案发现: ...", run_in_background: true)
Agent("Researcher", "按 W3 技术评估: ...", run_in_background: true)
Agent("Researcher", "按 W6 文献研究: ...", run_in_background: true)
中英双语调研时必须翻译搜索词。
微信公众号源（主线程处理）
当调研涉及微信公众号内容（关键词：公众号、微信文章、mp.weixin.qq.com），主线程使用 wechat-article-extractor skill 搜索，与 Researcher 子代理并行执行。子代理没有 Skill/Bash 工具，无法调用此 skill，所以必须由主线程负责。
全部完成 → 读各子代理摘要 → 汇聚结论。
汇编质量检查：汇聚多个子代理结果为综合文档时：
- 子代理摘要已包含 Top 3 来源 URL，优先使用这些来源构建"参考来源"章节
- 仅在需要补充细节、验证数据准确性、或来源不足时，才 Read 原始报告文件
- 综合文档末尾保留"参考来源"章节，标注哪些结论有多源交叉验证
Step 7: PERSIST
子代理已写报告和更新 INDEX.md。主线程确认：
- 文件路径正确
- INDEX.md 已更新
- 存储层级正确（项目级 vs 全局级）
Step 8: 输出 + 衔接
L1 输出
## 调研摘要
### 发现
- [关键发现 1-3]
### 建议
[简要建议]
L2/L3 输出
## 调研摘要
**报告位置**: `{绝对路径}`
### 关键发现（≤10 点）
1. [发现 1]
2. [发现 2]
### 复用分析
| 方案/项目 | 策略 | 理由 |
|-----------|------|------|
| {名称} | 🟢 直接用 / 🟡 借鉴 / 🔵 参考 / ⚪ 自己写 | {简述} |
### 推荐方案
[简述]
### PRD 框架草案（仅 W1 方案发现 / W3 技术评估时输出，W2/W4/W5/W6 跳过）
**推荐方案**: [从调研推荐方案提取]
**核心功能**: [从关键发现提取]
**技术依赖**: [从复用分析提取]
**风险项**: [从对抗性检验提取]
**待澄清**: [从不确定项提取]
调研完成后给出下一步建议：编码 → 研发模式 / 决策 → 选项+推荐。
可选：开源项目深度研究
在 W1（方案发现）或 W3（技术评估）执行过程中，发现借鉴意义高的开源项目时可触发：
- 主线程克隆到
~/projects/repos/{项目名}/（需要 Bash/git，Researcher 子代理没有）
- 更新
~/projects/repos/index.md
- 启动 Researcher 子代理做 Read-only 代码分析，报告保存到项目
docs/research/
调研阶段的行为约束
调研阶段专注于信息收集和分析，不进入编码实现：
- 调研阶段不写实现代码——调研完成后切换到研发模式再编码
- 不做最终技术决策——只提供建议和推荐，决策由用户做
GitHub 搜索规范（原 github-search skill，已合并）
搜索命令
gh search repos "<关键词>" --stars=">100" --sort=stars --limit=10
gh repo view <owner/repo> --json description,stargazersCount,updatedAt
筛选标准
| 指标 | 阈值 | 原因 |
|---|
| Stars | > 100 | 基本质量保证 |
| 最近更新 | < 6个月 | 活跃维护 |
| License | MIT/Apache/BSD | 商用友好 |
| Issues 关闭率 | > 50% | 维护者响应 |
| 有 README | 必须 | 基本文档 |
| 依赖数量 | 越少越好 | 轻量优先 |
| TypeScript | 优先 | 类型安全 |
| 测试覆盖 | 有则加分 | 代码质量 |
输出格式
对 Top 3 项目输出：项目名 + Stars + 链接、一句话描述、适用场景、潜在问题。
采用决策
| 方式 | 条件 | 行动 |
|---|
| 🟢 直接使用 | 功能完全匹配、维护良好、依赖可接受 | 安装并集成 |
| 🟡 借鉴实现 | 功能部分匹配、或依赖过重 | 阅读核心源码，理解关键逻辑后自己实现 |
在 W1（方案发现）的 SCAN/FILTER 步骤和 W3（技术评估）的 ORIENT 步骤中自动使用。
