القائمة
跑只读的深度仓库分析，返回一份带置信度排序的综合结论，附具体文件引用、清晰区分证据与推断。当用户说 '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 答复：