Skill: jackyujun/analysis-report (version 1.0.0)

--- name: analysis-report description: | 编排并生成完整的数据分析报告。当用户需要一份结构化的分析报告（而非单个指标查询或单点分析）时，必须使用此 Skill。本 Skill 是编排层——它不包含分析逻辑，而是知道"一份好报告该有什么内容"，按报告模板依次调度能力层 Skill（metric-query、anomaly-detection、metric-attribution、forecast-simulation）执行各板块分析，最后将结果串联为连贯的分析叙事。 触发场景包括但不限于：用户提到"出一份报告""月报""周报""分析报告""汇报""工作总结""经营分析""数据复盘""业绩回顾""出一份XX分析""帮我做个报告""总结一下上月情况""给老板看的报告""经营简报""数据报告"，或用户希望对某个业务领域做一次全面、系统的分析并输出文档时，都应使用此 Skill。 **触发判定关键**：用户想要的是一份**完整的、多板块的分析文档**，而非单个数据点查询或单项分析。区分方式： - "出一份月报""做个销售分析报告" → analysis-report（完整报告） - "上月销售额多少" → metric-query（单个数据查询） - "销售额有没有异常" → anomaly-detection（单项异常检测） - "以后每月都出月报" → scheduled-report（含"以后/每月"=定时意图） **与 scheduled-report 的区分**：本 Skill 管"现在就出一份报告"（一次性执行）；scheduled-report 管"以后定期出"（录制+定时重放）。判断依据是用户表达中是否包含"定时/定期/每X/以后都"等重复执行意图。没有 → 本 Skill；有 → scheduled-report。 **前提**：本 Skill 不直接查数据或做分析，所有分析工作委派给能力层 Skill。它的核心价值是报告结构知识和叙事编排能力。 --- # 分析报告编排 Skill ## 执行模式 - **强模型**（Claude Opus/Sonnet, GPT-4o/5）：遵循"原则"段落，自行决定实现细节 - **标准模型**（Qwen, DeepSeek, Llama）：严格按"模板"段落执行，使用提供的代码块，不要自行改写 > 如果你不确定自己属于哪个类别，请按"标准模型"模式执行。 ## 定位 本 Skill 是**编排层**，扮演"报告总编"的角色： 1. **知道一份好报告该有什么**——不同类型报告的标准板块和组织结构 2. **调度能力层 Skill 执行分析**——按报告结构依次调用 metric-query、anomaly-detection 等 3. **串联结果为连贯叙事**——不是把数据表格堆砌在一起，而是形成有逻辑的分析故事 它**不包含**任何分析逻辑——不自己查数据、不自己判异常、不自己做归因。 --- ## 整体流程 ``` ┌─────────────────────────────────────────────────────────────────┐ │ 报告生成流程 │ │ │ │ Step 1 理解需求：什么类型的报告？覆盖什么范围？ │ │ ↓ │ │ Step 2 确定报告结构：选择/生成报告模板 │ │ ↓ │ │ Step 3 逐板块执行分析：调度能力层 Skill │ │ ↓ │ │ Step 4 串联叙事，输出报告 │ │ │ └─────────────────────────────────────────────────────────────────┘ ``` --- ## Step 1：理解需求 ### 1.1 确定报告类型 从用户的表达中提取： | 提取项 | 说明 | 示例 | |-------|------|------| | **报告主题** | 分析什么业务领域 | 销售、库存、会员、运营 | | **报告周期** | 分析什么时间范围 | 上月、上周、上季度、本年至今 | | **受众** | 报告给谁看 | 老板（要结论和建议）、团队（要细节）、自己（要数据） | | **深度** | 全面概览还是深入分析 | 简报（核心KPI一页纸）vs 深度分析（含归因） | ### 1.2 模糊需求处理 **用户只说了领域**（"出一份销售报告"）： → 默认上月，标准深度，通过 metric-query 搜索该领域核心指标 **委派 metric-query 搜索指标**：关键词="销售"，返回数量=20 **用户完全模糊**（"出一份报告"）： → 询问报告主题和时间范围 **用户指定了受众**（"给老板看的月报"）： → 调整报告风格：结论前置、减少技术细节、突出行动建议 --- ## Step 2：确定报告结构 根据报告类型选择对应的模板。模板定义了报告的板块组成和每个板块应调用哪个能力层 Skill。 ### 2.1 通用报告模板 适用于大多数业务分析报告，可根据具体需求增减板块： ``` 一、核心指标概览 - 本期核心 KPI 一览表（值 + 环比/同比变化） - 调用：metric-query 二、趋势分析 - 核心指标的时间趋势（按月/按周展开） - 调用：metric-query（dimensions 含时间维度） 三、异常扫描 - 哪些指标/维度出现了异常波动 - 调用：anomaly-detection 四、异常归因（如有异常） - 对检测到的异常做根因分析 - 调用：metric-attribution 五、维度拆解 - 按关键维度（渠道/品牌/地区）拆分看各自表现 - 调用：metric-query + 排名/占比 六、目标达成（如有目标） - 目标完成情况 + 预测能否达标 - 调用：forecast-simulation 七、关键发现与建议 - 基于以上分析的结论和行动建议 - 由本 Skill 汇总各板块发现，生成叙事 ``` ### 2.2 板块裁剪规则 不是每份报告都需要全部板块： | 条件 | 处理 | |------|------| | 用户要"简报" | 只保留板块一 + 板块七 | | anomaly-detection 未发现异常 | 跳过板块四（归因） | | 用户没提目标 | 跳过板块六（目标达成） | | 用户指定了特定维度 | 板块五只做该维度 | | 报告周期是日报 | 简化板块二（趋势），聚焦板块三（异常） | ### 2.3 向用户确认结构 展示报告大纲，让用户确认： ``` 📋 报告大纲： 一、核心指标概览（销售额、客单价、转化率、订单数 + 环比同比） 二、月度趋势（近6个月走势） 三、异常扫描（检测各指标是否偏离正常范围） 四、异常归因（如发现异常，分析原因） 五、渠道拆解（各渠道表现 + TOP/BOTTOM 排名） 六、关键发现与建议 这个结构可以吗？需要增减什么板块？ ``` --- ## 板块间上下文传递（标准模型必做） 编排多个分析板块时，每个板块完成后将关键发现写入 `report_context`，确保后续板块能引用前面的结论。 ```python # 初始化上下文（在第一个板块开始前执行） report_context = { "report_title": "", # 报告标题 "time_range": "", # 分析时间范围 "kpi_summary": {}, # 板块一：核心 KPI 摘要 "trend_findings": [], # 板块二：趋势发现 "anomalies": [], # 板块三：异常检测结果 "attribution_findings": [], # 板块四：归因发现 "key_conclusions": [], # 最终结论汇总 } # ===== 板块一完成后 ===== report_context["kpi_summary"] = { "metrics": [ {"name": "销售金额", "value": 12345678, "change": -0.08, "direction": "下降"}, {"name": "客单价", "value": 680, "change": 0.03, "direction": "上升"}, ], "overall_assessment": "销售额下滑但客单价提升，量跌价升" } # ===== 板块三完成后 ===== report_context["anomalies"] = [ {"metric": "retail_amt", "dimension": "first_channel", "value": "Retail", "severity": "🔴", "detail": "Retail 渠道销售额环比下跌 18%"}, ] # ===== 板块四开始时（必须先读取 anomalies） ===== if report_context["anomalies"]: for anomaly in report_context["anomalies"]: print(f"归因目标：{anomaly['metric']} 在 {anomaly['value']} 的异常（{anomaly['severity']}）") # 对该异常调用 metric-attribution 能力 else: print("无异常，跳过归因板块") # ===== 板块六（结论）开始时 ===== # 汇总所有板块发现 for finding in report_context["trend_findings"]: report_context["key_conclusions"].append(finding) for finding in report_context["attribution_findings"]: report_context["key_conclusions"].append(finding) print(f"最终结论数量：{len(report_context['key_conclusions'])}") ``` **标准模型执行原则**： - 每个板块完成后，**立即**更新 report_context - 下一个板块开始前，**先读取** report_context 中相关字段 - 板块六（结论）必须引用前面板块的具体数据，不可凭记忆编造 --- ## Step 3：逐板块执行分析 按确认后的报告结构，**依次**调度能力层 Skill 执行各板块。 ### 3.1 执行顺序 严格按模板的板块顺序执行，因为后面的板块可能依赖前面的结果： - 板块三（异常扫描）的结果决定是否执行板块四（归因） - 板块五（维度拆解）的发现会纳入板块七（结论） ### 3.2 各板块的调用方式 **板块一：核心指标概览** → 调用 metric-query：查核心 KPI 及环比/同比 → 所需信息：指标列表、时间范围、对比基准 **板块二：趋势分析** → 调用 metric-query：dimensions 含时间维度，拉近 N 期数据 → 所需信息：指标列表、时间粒度、时间范围 **板块三：异常扫描** → 调用 anomaly-detection：对板块一中的指标做异常检测 → 所需信息：指标列表、检测维度、基线类型 **板块四：异常归因** → 调用 metric-attribution：对板块三发现的异常指标做归因 → 前置条件：板块三发现了异常 → 所需信息：异常指标、对比基准、归因维度 **板块五：维度拆解** → 调用 metric-query：按维度分组查询 + 占比/排名 → 所需信息：指标、维度、排名方式 **板块六：目标达成** → 调用 forecast-simulation：目标缺口分析 + 趋势预测 → 前置条件：用户提供了目标值 → 所需信息：目标值、当前累计值、剩余时间 ### 3.3 执行原则 **逐板块向用户展示中间结果**：不要等全部做完再一次性输出。每完成一个板块就展示该板块的结果，让用户可以随时调整方向。 **灵活应对**：如果某个板块的分析发现了用户可能关心的新角度，可以在展示时提议增加分析内容。 **板块间传递上下文**：后面的板块应引用前面板块的发现。例如板块四归因时说"在板块三中我们发现 Retail 渠道销售额异常下跌，下面分析原因..."。 --- ## Step 4：串联叙事，输出报告 ### 4.1 叙事编排原则 **先结论后细节**：报告开头用 2-3 句话概括全篇核心发现，然后再展开各板块细节。 **数据+洞察，不只是数字**：每个板块不只是表格，还要有一句解读。不是"Retail 渠道环比 -18%"，而是"Retail 渠道环比下跌 18%，是所有渠道中跌幅最大的，需要重点关注"。 **板块间有过渡**：不是孤立的数据块拼接，而是有逻辑链的叙事。"核心指标中，销售额环比下降 8%（板块一）。从趋势看，这已经是连续第二个月下滑（板块二）。异常检测显示 Retail 渠道是主要拖累（板块三）。归因发现..." **结论要有行动指向**：最后的"关键发现与建议"不能只是复述数据，要给出可执行的建议。 ### 4.2 输出格式 默认输出 Markdown 格式。报告结构： ```markdown # {报告名称} — {时间范围} > **核心摘要**：{2-3 句话概括全篇最重要的发现} ## 一、核心指标概览 {KPI 表格 + 简要解读} ## 二、趋势分析 {趋势描述 + 变化拐点标注} ## 三、异常扫描 {异常/正常的结构化结果} ## 四、异常归因 {针对异常指标的根因分析} ## 五、{维度}拆解 {TOP/BOTTOM 排名 + 占比分析} ## 六、关键发现与建议 {总结发现 + 可执行的行动建议} ``` 如果用户需要其他格式（docx / pptx / xlsx），在 Markdown 生成后调用对应的文档 Skill 转换。 --- ## 注意事项 ### 与能力层 Skill 的边界 本 Skill 是"总编"，不是"记者"。它决定报告需要什么内容，但每个内容板块的具体分析工作都交给对应的能力层 Skill。 - 需要查数据 → 委派给 metric-query - 需要判断异常 → 委派给 anomaly-detection - 需要解释原因 → 委派给 metric-attribution - 需要预测推演 → 委派给 forecast-simulation ### 与 scheduled-report 的边界 - 本 Skill："现在就出一份报告"（一次性） - scheduled-report："把这个过程录下来，以后定时出"（定时重放） 典型连续使用场景：用户先用本 Skill 出了一份月报 → 觉得不错 → 说"以后每月都这么出" → scheduled-report 接手，把本次 analysis-report 的过程录制为 cron 任务。 ### 不要过度分析 用户要的是"报告"，不是"论文"。每个板块点到为止，不需要把每个维度都穷尽分析。重点突出，篇幅适中。如果用户需要对某个板块深入，可以单独触发对应的能力层 Skill。 --- ## 常见错误模式 **❌ 自己做分析而不委派**：在报告中直接构建 metric-query 的请求体查数据。应该通过调用 metric-query Skill 的流程来获取数据。 **❌ 报告只有数据没有洞察**：每个板块只放了表格，没有解读。用户要的是分析报告，不是数据导出。 **❌ 板块之间孤立无关联**：板块三发现了异常，板块四的归因却没有引用。各板块之间应有明确的逻辑衔接。 **❌ 不确认结构就开始做**：直接按默认模板全量执行。用户可能只想要一份简报，不需要完整的 7 个板块。 **❌ 结论没有行动指向**："销售额下降 8%"不是结论，"Retail 渠道销售额连续两月下滑，建议排查该渠道近期的运营策略变化"才是结论。 **❌ 触发词混淆，误触发 scheduled-report**：用户说"出一份月报"（一次性）被当成"定时月报"处理。注意区分"出/生成/做"（一次性）和"每月/定期/定时"（重复执行）。


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)