| name | 06-helm |
| description | 中文项目申请书写作流程第 06 阶段工具：整体方案规划与项目主线收敛。 根据 05-synthesis 的综合视角和 topic.md，从前期调研结论中筛选出最适合申请书的核心问题、主技术路线和整体方案，输出供 07-outline 直接使用的结构化蓝图。
当用户输入 /grant-master:06-helm，或在 grant 工作流中需要从 synthesis 结论收敛为项目方案、确定申请书主线时，使用本 Skill。
本 Skill 是 05-synthesis 的下游、07-outline 的上游。 它只负责方案规划与收敛，不继续调研、不精读论文、不重新做 synthesis、不写申请书大纲或正文。
|
06-helm：整体方案规划与项目主线收敛
1. 阶段定位
本 Skill 负责中文项目申请书 workflow 的第 06 阶段：整体方案规划与项目主线收敛。
核心职责：
05_synthesis（current_view.md）+ topic.md
↓
06_helm（本 Skill）
├── 从调研结论中筛选核心问题与主技术路线
├── 规划整体系统方案与研究内容
├── 明确项目边界（做什么 / 不做什么）
└── 输出结构化蓝图供 07-outline 使用
↓
07_outline
要解决的问题：经过 synthesis 之后，已有很多可能方向、很多技术路线、很多 gap 线索。申请书不能什么都写。本阶段要收敛为一个聚焦、完整、创新、可验证的项目方案。
本 Skill 不继续调研，不精读论文，不重新做 synthesis，不写大纲，不写正文。
2. 工作目录规则
以 Claude Code 当前工作目录作为项目根目录。不硬编码任何绝对路径。所有路径都相对当前工作目录。
3. 状态管理边界
./workflow/proposal_state.yaml 只属于 auto 管理。本 Skill 不读取、不修改、不创建该文件。
4. 输入文件规则
helm 的职责是方案收敛。输入分为三级：
4.1 L1：主输入（默认必读）
这些文件决定 helm 能否工作。每次调用必须全部读取。
./topic.md
./workflow/05_synthesis/current_view.md
./workflow/05_synthesis/latest_result.yaml
./workflow/05_synthesis/evidence_ledger.yaml
| 文件 | 提供什么 |
|---|
current_view.md | 当前对领域和问题的综合理解——gap 在哪、现有方法局限在哪、可能方向有哪些 |
evidence_ledger.yaml | 每个 claim 的证据等级——哪些论断有证据支撑、哪些 gap 可信、哪些只能作为启发 |
latest_result.yaml | synthesis 是否认为已经 ready_for_helm——以及还剩哪些未解决的问题 |
若缺少任一 L1 文件，生成 blocked 版 helm_result.yaml，不要编造方案。
4.2 L2：证据索引（默认必读）
这些文件帮助 helm 判断调研全局状态，每次调用应读取：
./workflow/02_literature_plan/long_plan.yaml
./workflow/04_paper_digest/paper_index.yaml
./requirements.md
./applicant_profile.md
./CLAUDE.md
| 文件 | 提供什么 |
|---|
long_plan.yaml | 哪些调研任务已完成、哪些被跳过、长期调研路线 |
paper_index.yaml | 精读了哪些论文，每篇的被引/venue/与课题关联 |
requirements.md | 申报要求（项目类型、经费、年限、特殊约束） |
applicant_profile.md | 团队基础——能支撑什么规模/类型的方案 |
CLAUDE.md | 项目规则、特殊约束 |
4.3 L3：原始细节（按需追溯）
不要一开始全部读完。 只在需要验证某个 claim、gap、baseline 或技术路线的证据强度时，按以下路径追溯：
追溯入口：先从 evidence_ledger.yaml 的 claims[].sources[].report 字段定位到具体文件路径，再读取。
# 按需追溯的典型路径：
helm 想确认某个 gap 是否真的有证据
↓
先看 evidence_ledger.yaml 的 claims / gap_candidates
↓
找到对应 claim 的 sources[].report 路径
↓
读取该 report（如 workflow/04_paper_digest/round_02/reports/Q1/papers/P003.md）
L3 文件池：
workflow/04_paper_digest/round_XX/reports/{batch_id}/papers/*.md # 单篇精读报告
workflow/04_paper_digest/round_XX/digest_report.md # 某轮综合精读报告
workflow/03_academic_search/round_XX/search_summary.md
workflow/03_academic_search/round_XX/candidate_papers.md
workflow/02_literature_plan/round_XX/round_goal.md
workflow/01_topic/01_topic_card.md
追溯原则：每次追溯只读与当前要验证的具体问题直接相关的那个文件段落——不要通读整篇 report，不要在 L3 层做发现性浏览。
5. 核心约束
方案规划必须遵守以下约束，不得突破：
- 聚焦几个关键核心问题，不要过度扩充；
- 梳理技术路线，将关键问题串联，确保每个问题有对应的技术路线/方案进行解决；
- 每个保留的问题都必须有对应解决方法；
- 每个技术模块都必须服务核心问题；
- 每个方案主张都必须能够被验证；
- 不要把 synthesis 中的所有方向都塞进方案；
- 必须明确哪些方向不做，以及为什么不做；
- 如果候选方向过多无法收敛，应阻塞并请用户选择方向（最多提出 3 个选择问题）。
6. 执行流程
第 1 步：读取输入
- 读取所有 L1 文件：
topic.md、current_view.md、latest_result.yaml、evidence_ledger.yaml。确认 synthesis 已给出 ready_for_helm，理解 gap 线索、idea 候选、证据等级全景。
- 读取所有 L2 文件：
long_plan.yaml、paper_index.yaml、requirements.md、applicant_profile.md、CLAUDE.md。了解调研全局状态、精读覆盖面、申请约束和团队基础。
- 遇到需要验证的 claim 或 gap 时，按 evidence_ledger 的 sources 路径追溯 L3——只读相关段落，不全量通读。
第 2 步：构建候选问题池
从 synthesis current_view.md 的 E（Gap）、F（创新候选）节提取候选问题，评估每个候选问题的重要性、适合性、可验证性和风险。
第 3 步：构建候选技术路线池
从 synthesis current_view.md 的 F（创新候选）、G（技术路线）节提取候选路线，评估每条路线的创新性、可行性、验证方式和风险。
第 4 步：筛选与收敛
从候选池中严格筛选出关键核心问题和技术路线。
选择标准：与 topic 贴合 / 证据充分 / 问题重要 / 不足明确 / 方案可落地 / 创新点可表达 / 指标可验证 / 范围不过大 / 风险可控。
对被放弃的方向，明确其去向：background_only、future_work、dropped 或 need_more_research。
若此步无法收敛，阻塞，向用户提出最多 3 个选择问题。
第 5 步：规划整体方案
规划最终项目方案：项目主线、系统架构、关键模块（角色、方法、输入输出、模块关系）、数据流、控制流、回退机制、安全边界。
第 6 步：规划验证逻辑
规划验证方案：baseline、对比方案、核心指标、实验场景、模块级验证、端到端验证、仍需用户确认的指标。
第 7 步：明确项目边界
明确本项目做什么 / 不做什么 / 作为扩展 / 只在背景提及 / 暂时放弃，以及选择理由。
第 8 步：写输出文件
写所有 4 个输出文件（格式见 §7），每个文件写前先用 Read 工具读取对应参考模板。
第 9 步：产出物完整性自检
- 检查以下文件是否存在且非空：
workflow/06_helm/helm_report.mdworkflow/06_helm/scheme_blueprint.yamlworkflow/06_helm/decision_log.mdworkflow/06_helm/helm_result.yaml
- 将验证结果写入
helm_result.yaml 的 integrity 字段：
integrity:
all_outputs_present: true/false
checked_at: "<当前时间>"
missing_outputs: []
warnings: []
- 若
all_outputs_present: false → 设置 can_continue: false，不声称阶段完成。缺失 scheme_blueprint.yaml 时必须阻塞——07-outline 依赖此文件。
7. 输出文件结构
若 ./workflow/06_helm/ 不存在，先创建。
workflow/06_helm/
helm_report.md # 完整方案规划报告（给人看）
scheme_blueprint.yaml # 结构化蓝图（给 07-outline 读）
decision_log.md # 取舍决策记录（追溯用）
helm_result.yaml # 阶段状态（给 auto 读）
写每个输出文件前，用 Read 工具读取对应参考模板：
| 输出文件 | 参考模板 |
|---|
helm_report.md | references/helm_report_template.md |
scheme_blueprint.yaml | references/scheme_blueprint_template.yaml |
decision_log.md | references/decision_log_template.md |
helm_result.yaml | references/helm_result_template.yaml（含成功/阻塞两种格式） |
模板文件位置：本 Skill 目录下的 references/（如 skills/06-helm/references/）
按需读取：只在即将写某个文件时读取对应模板。
各文件职责
helm_report.md：12 节完整报告，含候选池、筛选过程、最终方案、验证计划、写作蓝图；scheme_blueprint.yaml：结构化蓝图，07-outline 直接读取，告诉 outline 如何组织申请书；decision_log.md：记录哪些方向被放弃及原因，供后续回溯；helm_result.yaml：阶段状态，can_continue / recommended_next_stage / quality 等字段供 auto 读取。
8. 阻塞规则
| 情况 | 处理方式 |
|---|
| L1 文件缺失（topic.md / current_view.md / evidence_ledger.yaml / latest_result.yaml） | 生成 blocked 版 helm_result.yaml，提示先完成对应上游阶段 |
| 候选方向过多无法收敛 | 阻塞，向用户提出最多 3 个选择问题（不要自行假设用户意图） |
9. 最终响应格式
已完成整体方案规划：
核心问题：[一句话]
主技术路线：[一句话]
研究内容：[X 项]
输出文件：
- workflow/06_helm/helm_report.md
- workflow/06_helm/scheme_blueprint.yaml
- workflow/06_helm/decision_log.md
- workflow/06_helm/helm_result.yaml
不采用方向：[X 项，见 decision_log.md]
关键风险与待确认问题：
1. ...
2. ...
下一步建议：进入 07-outline，根据 scheme_blueprint.yaml 生成申请书大纲。
阻塞时：说明缺少什么输入或方案无法收敛，提出最多 3 个问题，不生成方案文件。
10. 质量要求
- 所有正文输出使用中文；
- 不硬编码项目绝对路径，默认使用当前工作目录；
- 不读取、不修改、不创建
./workflow/proposal_state.yaml；
- 写输出文件前用 Read 工具读取对应参考模板，按需读取；
- 严格遵守 §5 核心约束，不生成多路线、多核心问题的发散方案；
- 必须明确不做什么，以及为什么不做；
- 创新点必须能被验证，不生成空泛创新点；
scheme_blueprint.yaml 必须足够结构化，让 07-outline 无需再做方案判断；- 不继续调研，不精读论文，不重新做 synthesis；
- 最终响应中不要执行其他 Skill。
