| name | analysis-plan-builder |
| description | 将用户的数据分析需求转化为结构化的分析计划并与用户确认。用户提出 BI 业务分析、数据探索、统计建模等需要规划的分析任务时使用。简单数据查询、公式明确的定量计算等流程简单、无需规划的任务不使用。 |
analysis-plan-builder
设计原则：行动优先
用户发出分析请求后最差的体验是"agent 一连串提问、什么都没做"。本 skill 要求：先收集上下文，再规划，最后根据信息充分性决定立即执行还是反问。 用户能看到信息不断收敛、分析在推进，同时保留随时打断纠偏的能力。
前置条件
开始规划前，确认以下信息已就绪：
- 用户问题的任务类型（如 BI 业务分析、数据探索、统计建模等）
Step 1: 上下文构建（Phase 1 — Context Gathering）
收集和补充构造分析计划所需的信息。本步骤应尽早执行，在向用户提问之前先通过工具获取尽可能多的上下文。
1.1 可用资源确认
确认当前可用的资源：
- 用户提供的数据文件或表
- 数据获取工具 / API
- 静态的域知识包
- 可获取业务领域模型的接口（后文称"语义层"），即能查询指标、维度及其关系的服务或工具
如果工具列表中包含 MCP 语义层工具（search_context / get_domain_overview / list_metrics 等），立即调用以获取域上下文：
- 推荐首个调用：
search_context(query=用户原始问题, domain=识别出的业务域) — 一次调用返回匹配的指标、口径、数据集和相关维度。
- 补充调用
get_domain_overview(domain) 了解域全貌（当 search_context 返回不足时）。
实时向用户同步发现：将 MCP 返回的关键信息（指标名、口径定义、可用维度、数据表）以简洁文本输出到 assistant 消息。用户可随时打断纠偏。
如果没有 MCP 工具可用 → 跳过语义层调用，直接进入 1.2。
1.2 按任务类型补充上下文
- BI 业务分析 → 继续 1.3 ~ 1.5
- 其他任务类型（数据探索、统计建模等）→ 继续 1.6
BI 业务分析
若用户已明确指定了分析的指标（如"分析 DAU 变化"），可跳过 1.3 和 1.4，直接到 1.5 确认指标角色。
1.3 业务上下文识别
判定业务类型（ToB / ToC / ToD / Mixed）和业务子类型（如ToC 下的工具类 / 内容社区 / 电商 / 游戏），判定依据参考 references/bi-business-type-guide.md
1.4 分析范围确认
- 根据业务类型和子类型，读取
references/modules 下对应的分析目录文件：
