用途：探索代码库，回答“X 如何工作”类问题，产出清晰的架构说明，帮助建立可用的心智模型而非带注释的源码。也用于改动前的代码走查，以及放置位置、归属和分层问题（例如“这段应该放在哪里”）。
两种模式： Explain（默认）：探索代码库并产出清晰解释。 Critique：先解释，再启动多个模型独立识别架构问题。
Explain 模式流程：
- 理解问题并评估复杂度。判断问题类型（子系统、功能流程、架构概览、运行时追踪）。若范围含糊，先说明自己猜测的解释，不追问，让用户纠正。简单问题（单一模块、小工具、窄问题）跳过 explorer，直接解释；复杂问题（跨多个文件/服务的子系统、横切功能、完整架构概览）先并行启动 explorer 再交给 explainer。存疑时偏简单。 2a. 复杂问题探索：将问题拆成 2–4 个并行探索角度，避免重复。以单条消息启动全部 explorer：subagent_type: generalPurpose，model 为配置的 how-explorer 模型（默认 composer-2.5-fast），readonly: true。每个 explorer 使用 references/explorer-prompt.md 基础提示，外加各自探索角度。探索者应先宽后窄（Glob 找目录、Grep 关键类型），沿调用链追踪，读真实代码而非猜文件名，直到能完整描述输入到输出路径，并记录非显而易见之处，返回结构化发现。 2b. 简单问题直接解释：启动单个 Task 子代理一次完成探索与解释，subagent_type: generalPurpose，model 为配置的 how-explainer 模型（默认 claude-opus-4-8-thinking-xhigh），readonly: true，读取 references/explainer-prompt.md 获取沟通风格与输出格式。
- 复杂问题综合：explorer 全部返回后，启动单个 Task 子代理综合发现，模型同上，调和重叠、解决矛盾，写成面向人的解释。
- 呈现：向用户展示 explainer 输出，可轻度润色或补充上下文，但不要大幅重写。
输出格式（按问题调整，并非每节都需要）：Overview（1–2 段，是什么、做什么、为何存在）；Key Concepts（重要类型、服务或抽象，简要定义）；How It Works（核心，按流程叙述触发、步骤、数据流向、决策点，引用具体文件与函数，非必要不放代码块）；Where Things Live（相关文件/目录简图）；Gotchas（非显而易见或意外之处、历史背景、已知尖锐边缘）。
Critique 模式：当用户要求架构问题、缺陷或改进而非仅理解时触发。步骤 1 先跑完整 explain 流程。步骤 2 生成批评者：在单条消息中按配置的 how-critics 列表每个模型各一个架构批评者（默认 claude-opus-4-8-thinking-xhigh、gpt-5.5-high-fast、composer-2.5-fast），均为 subagent_type: generalPurpose，readonly: true，读取 references/critic-prompt.md 模板，各自获得步骤 1 的解释、相关文件路径和 references/critique-rubric.md 评分表。步骤 3 主代理判断：作为务实负责人而非聚合器，将发现分为 Act on（现在值得修）、Consider（真实但成本收益不明）、Noted（有效但低优先级）、Dismissed（错误、缺上下文或风格偏好）。先呈现解释，再给出批判结论。
限制：以上流程与默认模型来自资料，实际可用性、收费与平台未提供。