菜单
跑只读的深度仓库分析，返回一份带置信度排序的综合结论，附具体文件引用、清晰区分证据与推断。当用户说 'analyze'、'investigate'、'why does'、'what's causing'，或在提任何改动方案之前需要跨文件的有据解释时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
oh-my-kimi 的目录入口，包含面向 Kimi CLI 的 agent、skill、hook 与 MCP 套件，衍生自 oh-my-* 谱系。
面向密钥、注入、authz/authn、不安全 IO、依赖与数据外泄风险的安全评审
证据驱动的追踪通道，在 Kimi 的 Agent 工具中编排互相竞争的 tracer 假设
LLM Wiki —— 跨会话持续累积的 markdown 知识库（Karpathy 模型）
面向作家的 agentic 记忆系统 —— 跟踪人物、关系、场景与主题
取消任何活跃的 oh-my-kimi 模式（autopilot、ralph、ultrawork、ecomode、ultraqa、swarm、ultrapilot、pipeline、team）
| name | analyze |
| description | 跑只读的深度仓库分析，返回一份带置信度排序的综合结论，附具体文件引用、清晰区分证据与推断。当用户说 'analyze'、'investigate'、'why does'、'what's causing'，或在提任何改动方案之前需要跨文件的有据解释时使用。 |
用这个 skill 通过只读的仓库分析回答用户的问题。目标是解释代码库对该问题最可能说了什么，而不是漂移到实现、调试表演或泛泛的修复方案里。
$analyze例子：
$analyze$plan / $ralplan$teamAnalyze 按契约只读。
如果建议下一步有用，把它限制成一个能减少不确定性的只读甄别探针。
先回答用户的真正问题。
显式保持证据与推断的区分。每条实质性主张都必须标记为以下之一：
永远不要把推断当成直接证据呈现。 永远不要把猜测当成推断呈现。 当代码库不能定论时，显式标出不确定性。
强证据优先于弱证据：
未经支持的推测不算证据。
并行探索可以用，前提是它提升质量并保持运行时安全。
$team。$team 可用。对复杂分析的一个不错默认拆分：
continue，从当前分析状态继续，而不是重新发现。把答复结构化，让用户能看出哪些已知、哪些是推断，以及综合的置信度。
[简短复述用户的问题]
| 排名 | 解释 | 置信度 | 依据 |
|---|---|---|---|
| 1 | ... | 高 / 中 / 低 | 最强的支撑证据 |
| 2 | ... | 高 / 中 / 低 | 为什么排次 |
| 3 | ... | 高 / 中 / 低 | 为什么仍然可能 |
path/to/file:line-line —— 这个工件直接展示了什么path/to/file:line-line —— 佐证一份好的 analyze 答复：