| name | index-deep-research-analysis-skills |
| description | 基于唐氏深度研究法的 A 股指数天气预报研究 skill。用于在指数研究场景下定义输入要求、首轮研究维度、证据标准、时效纪律、技术验证要求和最终报告格式。唐氏深度研究法的具体流程、轮次设计与发散-收敛执行方式，不在本 skill 中展开，Agent 应先加载 deep-research skill 了解并遵循其随机应变、轮次串行推进、最终兼顾广度与深度的研究方法。触发词：指数深度研究、指数天气预报、唐氏深度研究指数、上证指数研判、沪深300未来走势。 |
| argument-hint | 描述要研究的指数、预报窗口和额外关注点 |
指数深度研究天气预报
这是一个面向 Agent 的指数场景 Skill，用于使用唐氏深度研究法对 A 股指数开展天气预报式研究。
本 Skill 负责定义指数天气预报场景下的专属规范；唐氏深度研究法本身的具体流程、轮次设计和发散-收敛执行方式，必须通过加载 ../deep-research/SKILL.md 了解并遵循，包括根据新信息随机应变地调整方向、按轮次串行推进，以及最终形成兼顾广度与深度的高信息密度结论。
何时使用
- 用户要求对 A 股指数做深度研究
- 用户要求生成未来若干个交易日的指数天气预报
- 用户要求把预设研究维度直接作为第一轮探索方向
- 用户给了额外关注点，希望把它纳入指数研究框架
研究方法说明：本 Skill 默认就是在调用唐氏深度研究法做指数研究，因此 Agent 在执行本 Skill 时，应先加载 deep-research，再按本 Skill 的指数场景规范完成研究和输出。
与 deep-research 的关系
1. 加载要求
执行本 Skill 时，应先加载 deep-research，再应用本 Skill。
原因如下：
- 本 Skill 的研究方法默认就是唐氏深度研究法
- 本 Skill 只定义指数天气预报场景，不重复展开通用方法论
- 唐氏深度研究法的具体流程、轮次设计、归档方式、随机应变原则和串行迭代节奏统一以 deep-research 为准
2. 本 Skill 负责什么
- 指数研究任务的初始化输入要求
- 第一轮探索维度的固定来源与执行方式
- 证据链、来源可信度和时效性标准
- 技术面与技术指标验证要求
- 指数天气预报报告的结构与表述纪律
3. 本 Skill 不再重复什么
- 唐氏深度研究法的流程细节
- 通用的轮次设计与停止条件
- 通用的研究归档目录结构
指数研究执行规范
1. 初始化
开始执行前，先固定以下输入：
- 当前时间
- 指数名称
- 指数代码
- 研究基准日期
- 预报天数
- 用户额外关注点
- 数据与信息源的最新时间点
初始化时至少要确认：
- 当前时间是什么时候
- 研究基准日期与当前时间是否一致
- 行情数据更新到哪个交易日、哪个时点
- 事件、新闻、政策、资金等信息分别更新到什么时候
- 是否存在盘中、收盘后、隔夜或跨日的信息错位
预报天数优先服从用户要求；如果用户未指定，默认输出未来 5 个交易日。预报窗口越长，证据链和不确定性说明也必须同步增强。
2. 第一轮探索
第一轮探索方向必须直接读取 config/queries.json 中定义的研究维度。
这些维度本身就是第一轮任务，不要先做一轮笼统总述，再象征性引用配置。
执行要求：
- 每个维度单独形成一个探索任务
- 每个任务至少输出：核心结论、影响路径、证据链、不确定性、下一轮线索
- 用户额外提出的研究诉求，应作为附加探索方向并入第一轮，或明确纳入下一轮
- 不要只挑容易分析的维度，难分析但关键的方向也必须覆盖
- 第一轮就要同时纳入支持主线、挑战主线、可能推翻主线的不同证据
其中“技术指标验证”维度必须被当成独立任务处理，而不是作为附属说明带过。
3. 证据标准
- 不能只给观点，必须说明影响路径和对应证据
- 不能把一手数据、二手信息、推断性判断混写成同一可信度
- 如果关键判断只得到单一来源支持，必须明确标注其不确定性
- 如果关键数据拿不到，要明确标记证据缺口，不能虚构
来源可信度可按以下原则粗分：
- 高可信：交易所、监管机构、官方统计口径、直接行情数据、工具直接计算结果
- 中可信：主流财经媒体、专业数据服务、权威机构解读
- 低可信：社交媒体传闻、未证实聊天记录、缺乏原始出处的二手转述
低可信来源只能作为线索，不能直接作为核心结论依据；若无法独立验证，应降级提及或舍弃。
4. 时效纪律
- 研究开始前先确认当前时间，再判断已有信息是否足够新鲜
- 不要把不同时间点的信息直接揉成一个确定结论
- 每个重要判断都应尽量标明信息时间点和数据新鲜度
- 如果信息时间不明确或更新不及时，要主动降低结论置信度并说明原因
- 如果关键信息可能已经过时，必须显式指出其失效风险
5. 技术验证
如果环境中有指数或股票行情能力，应主动用于：
- 获取近期行情与成交信息
- 获取多周期 K 线或结构背景
- 补充关键支撑、压力与趋势验证点位
如果运行环境中可使用 Python，且 TA-Lib 或同类工具可用，应主动纳入技术指标验证。重点可包括：
- MA、EMA
- MACD、RSI、KDJ、ADX
- Bollinger Bands、ATR
- OBV 与量价关系
- 指标背离、趋势强弱、关键支撑压力验证
引用技术指标时，要说明这些指标支持什么判断、否定什么判断、在什么条件下可能失效，而不是只堆指标名称。
最终输出
最终报告应至少包含：
- 今日天气回顾
- 未来若干交易日天气预报表格
- 今日盘面复盘
- 未来走势研判
- 操作建议
- 风险提示
若条件允许，报告中应尽量明确：
- 研究生成时的当前时间
- 行情数据截至时间
- 重要外部信息截至时间
- 关键判断主要依据的数据或信息来源类型
如果数据覆盖不足，也要输出完整报告，但必须明确区分：
- 哪些部分基于已验证证据
- 哪些部分属于低置信度判断
- 哪些关键变量仍待验证
- 哪些结论可能受信息滞后影响
实践要点
关于执行方式
- 整个流程由 Agent 自主编排执行，不要把执行责任推回给用户
- 除非研究对象本身存在歧义，否则不要频繁中断用户逐轮确认
- 研究维度是第一轮探索方向，不要跳过
- 主动保持发散思维，不要满足于最顺手、最常见、最省力的解释框架
关于表述纪律
- 在最终结论中区分高置信度判断与低置信度判断
- 尽量给出触发天气变化的验证条件，而不是只给静态观点
- 不要把猜测写成事实，不要把概率判断写成确定判断
- 在表述上区分“已确认”“较大概率”“待验证”“传闻/线索”四种状态
- 如果无法确认来源可靠性，就宁可少写，也不要硬编或强行下结论
关于报告风格
- 报告风格保持天气预报化，但执行编排交给 Agent 框架
- 允许用户自定义关注点，并把它纳入研究过程
- 不提及任何特定外部研究平台
- 不携带运行时脚本、提示词模板或模型配置
天气标签可按需要使用：
- ☀️ 大晴天
- 🌤 晴
- ⛅ 多云转晴
- 🌥 多云间晴
- ☁️ 多云
- 🌦 阴
- 🌧 小雨 / 中雨
- ☔ 大雨
- ⛈ 暴雨
- 🌈 雨后转晴
- ❄️ 寒流
