| name | analyze |
| description | 跑只读的深度仓库分析，返回一份带置信度排序的综合结论，附具体文件引用、清晰区分证据与推断。当用户说 'analyze'、'investigate'、'why does'、'what's causing'，或在提任何改动方案之前需要跨文件的有据解释时使用。 |
Analyze — 只读深度分析
用这个 skill 通过只读的仓库分析回答用户的问题。目标是解释代码库对该问题最可能说了什么，而不是漂移到实现、调试表演或泛泛的修复方案里。
何时使用 $analyze
- 用户想要一份有据可依的解释，不要代码改动
- 答案需要读多个文件或跨边界追踪行为
- 存在多个合理解释，需要排序
- 置信度应当反映可得证据的强度
- 用户想在动手前理解架构、行为、因果、影响范围或权衡
例子：
- 为什么一个工作流是某种行为
- 一个功能在模块之间是如何串起来的
- 哪种假设最能解释一次失败、回归或不一致
- 修改某个依赖或契约会影响什么
- 对当前代码库来说哪种解读最有支撑
不要在以下情况使用 $analyze
- 用户明确想要代码编辑、修复或执行 —— 用对应的实现 lane
- 用户想要新的产品方案或验收标准 —— 用
$plan / $ralplan
- 请求是简单的单文件事实查询 —— 直接读文件并答复
- 请求只是为了跑 oh-my-kimi 的 tmux team 运行时 —— 只在 oh-my-kimi 运行时启动时用
$team
不可妥协的契约
Analyze 按契约只读。
- 不要编辑文件。
- 不要把答复变成实现计划。
- 不要把修复方案当作主输出。
- 不要悄悄切到执行工作。
- 不要过度声称确定性。
- 不要发明仓库证据不支持的事实。
- 不要使用超出证据范围的评判性、规范性或推测性语言。
如果建议下一步有用，把它限制成一个能减少不确定性的只读甄别探针。
与问题对齐的综合
先回答用户的真正问题。
- 从用户问的问题出发，而不是从泛用 debugger 模板开始。
- 把综合的范围限定在用户需要知道的内容上。
- 深度匹配请求：对简单或明显的问题，降低 swarm 强度，读够之后直接回答。
- 对范围更宽的问题，扩大搜索面，但保持最终答复紧凑。
证据规则
显式保持证据与推断的区分。每条实质性主张都必须标记为以下之一：
- 证据 —— 由具体仓库工件直接支持
- 推断 —— 从证据出发推得的结论
- 未知 —— 当前仓库证据无法解决的问题
永远不要把推断当成直接证据呈现。
永远不要把猜测当成推断呈现。
当代码库不能定论时，显式标出不确定性。
可接受的证据
强证据优先于弱证据：
- 带具体文件引用的代码路径、契约、测试、生成物、配置或文档
- 多个独立文件指向同一结论
- 由结构良好的代码推出的局部行为推断
- 较弱的上下文线索，并显式标记为 tentative
未经支持的推测不算证据。
并行探索策略
并行探索可以用，前提是它提升质量并保持运行时安全。
- 默认是直接的只读分析，答案简单时不要并行。
- 当并行有助益时，默认优先使用 native subagent，或在可用时用等价的会话内并行探索。
- 各并行 lane 要有边界：每个 lane 回答一个具体子问题或检查一个具体子系统。
- 仅在 oh-my-kimi 运行时启动且确实需要持久的 tmux 协调时用
$team。
- 不要在普通 Codex/App 会话里暗示
$team 可用。
对复杂分析的一个不错默认拆分：
- 一个 lane 负责主代码路径 / 契约
- 一个 lane 负责配置 / 编排 / 生成产物
- 一个 lane 负责测试 / 文档 / 二级佐证
执行策略
- 默认采取「outcome-first」的推进与完成汇报：先给出问题、证据、推断边界与停止条件，再补流程细节。
- 把用户新的任务更新当作当前工作流分支的本地覆盖，同时保留此前不冲突的约束。
- 如果用户说
continue，从当前分析状态继续，而不是重新发现。
工作方法
- 用一句话复述问题。
- 找出最可能给出答案的最小文件集。
- 先读直接证据。
- 需要时开有边界的并行探索 lane。
- 比较相互竞争的解释。
- 按支撑强度对解释排序。
- 给出一份明确区分证据与推断的综合。
输出契约
把答复结构化，让用户能看出哪些已知、哪些是推断，以及综合的置信度。
问题
[简短复述用户的问题]
排序综合
| 排名 | 解释 | 置信度 | 依据 |
|---|
| 1 | ... | 高 / 中 / 低 | 最强的支撑证据 |
| 2 | ... | 高 / 中 / 低 | 为什么排次 |
| 3 | ... | 高 / 中 / 低 | 为什么仍然可能 |
证据
path/to/file:line-line —— 这个工件直接展示了什么path/to/file:line-line —— 佐证
推断
未知 / 限制
- 仓库证据没有确定的事
- 下一步要查什么才能减少不确定性
质量基线
一份好的 analyze 答复：
- 只读且与问题对齐
- 排序的，而非平铺的
- 显式声明置信度
- 文件引用具体
- 谨慎区分证据与推断
- 没有未受支持的推测
- 没有规范性漂移或评判性的废话
- 显式区分证据与推断
- 简单情形保持简短，只有当问题真的需要时才扩大范围
