<使用时间> * 用户说“分析”、“调查”、“调试”、“为什么”或“原因是什么” * 用户在进行更改之前需要了解系统的架构或行为 * 用户想要对错误或性能问题进行根本原因分析 * 用户需求对拟议变更的依赖性分析或影响评估 * 复杂的问题需要读取多个文件并对其进行推理 <何时不使用> * 用户希望进行代码更改 - 使用执行代理或“ralph”代替 * 用户想要一个带有验收标准的完整计划——使用“计划”技能代替 * 用户想要快速文件查找或符号搜索 - 使用“explore”代理 * 用户提出一个简单的事实问题，可以从一个文件中回答 - 只需直接阅读并回答深入调查需要采用不同于快速查找或代码更改的方法。分析任务需要广泛的上下文收集、跨文件推理和结构化发现。将这些路由到架构师代理或 Codex 可确保正确的深度级别，而无需承担完整规划或执行工作流程的开销。 <执行策略> * 如果可用，首选 Codex MCP 进行分析（更快、成本更低） * 当 Codex 不可用时，退回到架构师代理 * 始终向分析工具提供上下文文件以进行有根据的推理 * 返回结构化结果，而不仅仅是原始观察结果 * 默认为简明、证据密集的进度和完成报告，除非用户或风险级别需要更多细节 * 将较新的用户任务更新视为活动工作流分支的本地覆盖，同时保留早期的非冲突约束 * 如果正确性取决于额外的检查、检索、执行或验证，请继续使用相关工具，直到分析有依据 * 自动继续执行清晰、低风险、可逆的后续步骤；仅当下一步是实质性分支、破坏性或依赖于偏好时才询问 <工具_用法> * 在第一次使用 MCP 工具之前，调用 `ToolSearch("mcp")` 来发现延迟的 MCP 工具 * 使用 `ask_codex` 和 `agent_role: "architect"` 作为首选分析路径 * 将 `context_files` 与所有相关源文件一起传递以进行基础分析 * 当 ToolSearch 找不到 MCP 工具或 Codex 不可用时，使用“架构师”角色作为后备 * 对于广泛的分析，首先使用“explore”代理来识别相关文件，然后再路由到架构师 ## 场景示例 **好：** 在工作流程已经有了明确的下一步之后，用户说“继续”。继续当前的工作分支，而不是重新启动或重新提出相同的问题。 **好：** 用户仅更改输出形状或下游交付步骤（例如“制作 PR”）。保留早期不冲突的工作流程约束并在本地应用更新。 **不好：** 用户说“继续”，工作流程会重新启动发现或在收集缺少的验证/证据之前停止。 <升级和停止条件> * 如果分析显示问题需要更改代码，请报告结果并建议使用“ralph”或执行器进行修复 * 如果分析范围太宽泛（“分析一切”），请用户缩小焦点 * 如果 Codex 不可用并且架构师代理也失败，请报告收集到的上下文并建议手动调查路径 <最终清单> * 分析针对特定问题或调查目标 * 调查结果参考具体文件和行号（如果适用） * 确定根本原因（不仅仅是症状）以进行错误调查 * 提供可行的建议 * 分析区分已证实的事实和假设任务：{{参数}}

分析

包含技能