| name | cross-analysis |
| description | 面向“围绕一个明确目的，对照多个参考源的实现、做法或边界来形成判断”的调研分析型任务。适用于交叉分析、对标调研、竞品分析、参考已有软件怎么做、围绕某个主题找多个参考源对照等请求；当需要先找到合适参考源，再展开分析、比较、综合时，应触发此 skill。默认用于运行态交叉分析，只有在用户明确要求新增、补充或整理本地参考源时，才进入维护态。触发关键词：交叉分析、对标调研、竞品对比、参考源对照、多个参考源、调研分析、为什么参考X而不是Y、应该参考哪些。 |
交叉分析
这个 skill 的目标是：
围绕用户给定的“目的”，优先调用已经沉淀的参考源，对照这些参考源在相关主题上的实现、做法与边界，产出可供用户继续使用的交叉分析结论。
这个 skill 的重点不在“最后把结果写到哪里”，而在：
- 先识别用户真正的目的
- 再找最合适的参考源
- 再围绕该目的做对照分析
结果与形式由用户决定，不由本 skill 预先限定。
使用状态
这个 skill 有两种状态，但默认按“运行态”使用。
除非用户明确要求：
- 新增一个本地参考源
- 补充一个已有本地参考源
- 整理参考源索引或维护章程
否则都应优先按“运行态”理解，而不是先进入维护态。
1. 运行态（默认）
用于围绕一个明确目的，调用现有参考源做交叉分析。
此时重点是：
2. 维护态（少用）
用于新增、补充或整理本地参考源。
维护态的具体做法见：
核心概念
目的
“目的”是用户真正想推进的问题，不是一个孤立关键词。
例如：”本地化笔记该优先参考哪些成熟做法”、”DAG动画增强该参考哪些现有实现”。
交叉分析必须围绕”目的”展开，而不是围绕某个产品名称机械摘要。
参考源
“参考源”是可持续积累、可重复调用的对照对象，可以是本地档案、GitHub项目、官方文档或产品级参考对象。
本地 source-*.md 档案是”外部参考的本地化搜索指南”，帮助 Agent 定位参考源，不替代对 ExoMind 自身现状的内部核查。
内部参考与外部参考
当问题围绕 ExoMind 自身功能、代码、issue/PR 展开时，先区分：
内部参考：当前仓库与项目自身已有的代码、文档、网站页面、issue/PR外部参考：仓库之外的开源项目、官网、帮助中心、产品网站等
默认原则：与 ExoMind 自身实现直接相关的问题，先查内部参考；需要对照外部成熟做法时，再进入外部参考。
外部参考默认按”只读”处理——用来对照、借鉴、提炼模式与边界，不把外部仓库当作当前任务的可修改对象。
本 skill 的职责边界
本 skill 负责：明确目的、选择参考源、对照分析、输出结构化结论。
本 skill 不负责强制规定最终写回位置、写成何种计划文档或生成何种固定模板报告。
参考源优先级
如果问题直接围绕 ExoMind 自身当前实现，默认按以下顺序取材，只有上一层不足时才进入下一层：
- 内部参考
- 本地参考源档案
- 外部 GitHub / 官方文档 / 产品网站
- 搜索型 skill
- Agent 自行网页搜索
如果问题本身不是围绕 ExoMind 当前实现，而是纯外部对标或通用调研，可从：
- 本地参考源档案
- 外部 GitHub / 官方文档 / 产品网站
- 搜索型 skill
- Agent 自行网页搜索
Before 做交叉分析
在做交叉分析之前，先问自己：
- 目的：用户真正想解决什么问题？不是关键词是什么
- 范围：需要内部参考吗？还是纯外部对标？
- 深度：选 2-5 个参考源，为什么这 2-5 个能形成互补？
- 判断：共性是什么？分歧在哪里？推荐路径是什么？
标准流程
以下流程默认面向“运行态”。
1. 先明确用户目的
先把用户真正想分析的”目的”收敛出来。
至少要明确：
- 主题是什么
- 用户想借这次分析解决什么问题
- 用户更关心实现、产品做法、交互方式，还是边界约束
若用户目的模糊或分散：
- 先内部归纳成一句话：”这次要围绕什么目的做参考源对照”
- 用这句话向用户确认
- 得到确认后再继续，不要在目的模糊时就开始分析
2. 若与 ExoMind 自身相关，先查内部参考
如果用户的目的本身是在分析：
- ExoMind 当前功能
- 外心官网 / 用户教程 / 应用内文档
- 当前代码实现
- 当前 issue / PR / GitHub 内容
那么先检查内部参考。
优先看：
- 当前仓库里的代码、文档、网站页面
- 当前 issue、PR、计划文档
- 当前 GitHub 上已存在的公开内容
这里的第一步目标是：
- 先确认 ExoMind 现在已经有什么
- 先确认当前问题到底缺什么
- 避免在没有看现状的情况下，直接去外部找答案
3. 再查本地参考源
先查看本地是否已有相关参考源档案。
优先读取：
skills/cross-analysis/references/ 下的索引和相关档案
这里的第一步目标是：
- 找到相关参考源
- 确定优先检索路线
- 明确下一步该去哪个本地档案、GitHub 项目或官方资料
如果本地已有与当前目的高度相关的参考源，就优先沿这些线索展开。
不要跳过本地参考源，直接外搜。
4. 再补外部参考源
当本地参考源不够时，再去补 GitHub 或其他来源。优先顺序：GitHub 开源项目 > 搜索型 skill > 网页搜索。
为什么选 2-5 个参考源？
- 少于 2 个：无法形成对照，单一参考等于没有分析
- 超过 5 个：边际收益递减，且增加综合难度
- 2-3 个：适合相似类型对象对照（如两个竞品）
- 3-5 个：适合跨越类型对照（如 1 个竞品 + 1 个开源 + 1 个文档）
筛选标准：与用户目的的相关度、技术栈或产品形态相似度、能否形成互补对照。
外部参考默认只读。这里的重点是：看外部对象怎么做、抽象可借鉴模式与边界、再回到 ExoMind 当前现状做对照。不要把外部仓库或网页当作当前任务的可修改对象。
5. 可并行时再拆给 subAgent
只有在多个参考源调查彼此独立时，才拆给多个 subAgent。
推荐方式：
- 每个参考源一个 subAgent
- subAgent 只做该参考源的只读调查
- 主代理负责综合与抽象
不要让 subAgent 混合调查多个参考源。
6. 统一每个参考源的分析维度
每个参考源至少回答：
- 这个参考源为什么与当前目的相关
- 它在这个主题上是怎么做的
- 这些做法落在哪些实现位置、模块位置或功能位置
- 它的边界、约束与默认策略是什么
- 哪些点值得借鉴，哪些点不该直接照搬
如果能拿到精确源码位置，就明确列出；如果拿不到源码，只能作为产品参考时，也要明确标注。
推荐覆盖的分析维度：
- 实现位置、产品做法、交互效果、状态边界、数据边界、可扩展性、耦合风险
- 主题偏实现时优先看：源码入口、组件或模块分层、状态与持久化边界
- 主题偏产品时优先看：交互模式、信息组织方式、用户感知到的行为、功能边界与默认策略
7. 最后做交叉综合
最终综合时，不要写成参考源流水账。
应该回答：
- 多个参考源之间有哪些共性
- 它们在哪些地方分歧明显
- 对于当前“目的”，哪些路径更值得优先考虑
- 哪些参考源适合作为长期参考对象
不要把结果写成“逐个参考源复述”的堆叠摘要。
运行态输出建议
运行态产出默认应显式包含一段：
这一段至少说明：
- 这次是否先查了 ExoMind 的内部参考，查了哪些
- 这次分析先命中了哪些本地参考源档案
- 这些本地参考源把后续检索导向了哪些官方资料、GitHub 项目或其他来源
- 哪些来源是补充性的，为什么需要补
- 最终保留了哪些参考源进入交叉分析，为什么它们与当前目的相关
如果同时用了内部参考与外部参考，也应明确写出：
- 哪些判断来自 ExoMind 当前现状
- 哪些判断来自外部对照对象
- 最后是如何把两者对照起来的
如果这次没有命中本地参考源，也要明确写出：
- 为什么本地索引不足
- 因此是如何进入 GitHub、搜索型 skill 或网页搜索的
这样做的目的不是固定报告模板，而是让运行态结果具备可审阅性，能看出 Agent 是否真的遵循了“先本地参考源、再外部补充”的路线。
反模式
不要这样做：
- 一上来就网页搜索
- 列一堆参考源但没有围绕用户目的筛选
- 只讲“这个产品很像”，却不说明为什么相关
- 把本地已沉淀的参考源档案完全跳过
- 强行规定结果必须写到某种固定载体
- 在没有对照维度的情况下输出一大段松散摘要
最小检查清单
- 已明确用户目的
- 已先检查本地参考源档案
- 已按优先级决定是否需要外部补充
- 已控制参考源数量，不无上限扩展
- 已统一每个参考源的分析维度
- 已完成交叉综合，而不只是逐个摘要
