用途
researching 是一项代码库研究技能，目标是围绕某个研究问题，对代码库进行全面的调研，并把代码库的现状（as-is）整理成研究文档。它是技术地图与现有系统的文档化工作，而非代码评审或改造建议。
该技能在以下情形被激活：用户调用 /research 命令；其他技能引用 “REQUIRED SUB-SKILL: Use desplega:researching”；用户要求记录或理解某个代码库领域。
主要能力与工作约定
- 所有面向用户的提问通过 AskUserQuestion 进行（非 Autopilot 模式下），不在聊天中以普通列表形式提问。
- 所有读取与研究类工作都交由子代理完成，避免把原始工具输出留在主会话中，默认使用 run_in_background: true。
- 文件评审（file-review）默认开启，在研究文档就绪时调用（Autopilot 模式可跳过）。
- 关键约束：除非被明确要求，不提出改进或变更、不做根因分析、不提出未来增强、不批判实现或指出问题、不建议重构/优化/架构调整；只描述存在什么、在哪里存在、如何工作。
自治模式
研究开始时根据自治模式调整交互程度：
- Autopilot：独立工作，尽量减少提问，最后呈现完整结果。
- Critical（默认）：仅在受阻或涉及重大范围/方向决策时提问。
- Verbose：频繁确认，每一步验证方法，继续前先确认。
自治模式由发起命令传入，未指定时默认 Critical。
使用方式与研究流程
- 先前学习召回（可选）：若存在 ~/.agentic-learnings.json，先运行 /learning recall <current topic> 检查相关既有学习。
- 设计文档：若所研究系统存在设计文档（thoughts/*/design-docs/<system-slug>.md），先阅读，并在研究文档中使用其 Glossary 术语。当代码与文档的 Invariants 或 Boundaries 冲突时，在发现中明确标注冲突（“doc says X, code does Y”），而不是绕开它静默记录。
- 开始前：先对研究问题做快速分析；若有不清晰之处且非 Autopilot，用 AskUserQuestion 澄清。若会话中可用 Workflow 工具且查询确实需要 3 个以上研究领域的大规模展开，可在同一次 AskUserQuestion 中附加询问是否以 Workflow 脚本编排研究展开（“Yes — Workflow fan-out” / “No — plain Task agents”默认为否）；只有明确同意才算 Workflow 工具的 opt-in，若工具不可用或处于 Autopilot（未询问即未 opt-in），则使用普通 Task 代理。
- 先完整读取用户直接提到的文件（Read 工具不带 limit/offset 参数），并在派生子任务前自己先读文件。
- 分析并拆解研究问题，识别组件、模式或概念，用 TodoWrite 创建研究计划追踪子任务。
- 派生并行子代理任务：代码库研究用 codebase-locator 定位文件与组件位置、codebase-analyzer 理解具体代码如何工作、codebase-pattern-finder 查找现有模式示例；库与框架研究用 context7 MCP 获取文档；仅在明确要求时用 web-search-researcher 做外部文档研究；嵌套研究可用 /research <topic> 深入。若可用 desplega:delegate-work，按其矩阵为每个子代理选模型而非使用默认值（定位/模式查找/摘要 → Haiku，分析 → Sonnet）。若已 opt-in Workflow fan-out，则将第 3–4 步作为一个 Workflow 脚本运行，每个研究领域一个 agent()，合成前设屏障；合成与文档撰写（第 5 步起）仍在主会话进行，工作流只返回发现，绝不写研究文档。
- 等待所有子代理完成，汇总发现：以实际代码库发现为主要来源，连接不同组件，包含具体文件路径与行号。
- 生成研究文档：若在 plan 模式先退出；写入 thoughts/<username|shared>/research/YYYY-MM-DD-topic.md；路径选择上，若上下文可确定用户名则用 thoughts/taras/research/ 这类形式，否则回退到 thoughts/shared/research/；遵循模板 cc-plugin/base/skills/researching/template.md，模板包含带元数据（日期、研究者、git 信息、标签、状态）的 YAML frontmatter、标准章节（Research Question、Summary、Detailed Findings、Code References 等）以及 file:line 引用格式。
- 如适用（在 main 分支或提交已推送）添加 GitHub 永久链接。
- 同步并呈现发现：给出带关键文件引用的简洁摘要；若不在 Autopilot，询问是否有后续问题。
- 提供结构化评审：询问是否对研究文档运行 /review 做质量检查，若同意则调用 desplega:reviewing 技能。
- 处理后续问题：追加到同一研究文档，更新 frontmatter 的 last_updated 字段，必要时派生新的子代理。
- 学习捕获（可选）：若过程中出现重要洞见、模式、易错点或决策，可考虑用 desplega:learning 通过 /learning capture 记录，重点关注对他人未来会话有帮助的内容。
- 工作流交接：研究完成（并可选评审）后，用 AskUserQuestion 询问下一步：1. 基于本研究创建计划（→ /create-plan），2. 先运行评审（→ /review），3. 暂时结束。对应地，建议以研究文件作为输入上下文的 /create-plan、或调用 desplega:reviewing 评审研究文档、或无需进一步操作。
适用场景
需要理解或记录某个代码库区域、为后续规划准备事实性技术资料、或需要把跨组件调研结果整理为自包含研究文档的场景。
限制与注意事项
- 始终使用并行 Task 代理以提升效率。
- thoughts/ 目录提供历史上下文。
- 聚焦于找到具体的文件路径与行号。
- 研究文档应当自包含。
- 强调：你是记录者而非评估者；记录“是什么”，而非“应该是什么”。
- 关于收费、价格、平台支持等商业信息，资料中未提供。