idea-discovery

工作流 1：创意发现流水线

每个评审环节开始前，请遵循 可选评审者： 按顺序解析调用参数 → .aris/reviewer.json → Claude Code 默认值（Codex MCP）， 通过规范的辅助解析器调用 reviewer_route.py，同时保留此环节的层级、新上下文、 来源／图像输入和确定性门槛。 下方的 Codex 示例／固定配置仅适用于 backend=codex；其他路由使用各自的首次调用／回复约定。保存路由和实际返回的身份； 不可用的选择标记为 REVIEW_UNAVAILABLE。根据实际的模型系列／完成情况／范围进行判定。 将调用参数中的评审者／模型／effort 覆盖值 传递给包含评审者的子流程。生成工作进程保持不变。

为以下内容编排完整的创意发现工作流：$ARGUMENTS

概述

此技能将多个子技能串联为一个自动化流水线：

/research-lit → /idea-creator → /novelty-check → /research-review → /research-refine-pipeline
  (survey)      (brainstorm)    (verify novel)    (critical feedback)  (refine method + plan experiments)

每个阶段都基于前一阶段的输出。最终交付物包括经过验证、包含排名创意的 idea-stage/IDEA_REPORT.md，以及针对首选创意完善后的提案（refine-logs/FINAL_PROPOSAL.md）和实验计划（refine-logs/EXPERIMENT_PLAN.md）。

常量

• PILOT_MAX_HOURS = 2 — 跳过预计每块 GPU 耗时超过 2 小时的试点实验。在报告中标记为“需要手动试点”。
• PILOT_TIMEOUT_HOURS = 3 — 硬性超时：终止任何运行时间超过 3 小时的试点。如有部分结果，请收集。
• MAX_PILOT_IDEAS = 3 — 最多并行对排名前 3 的创意进行试点。其余创意仅通过文献和分析进行验证。
• MAX_TOTAL_GPU_HOURS = 8 — 所有试点的 GPU 总预算。如果超出，则跳过其余试点并在报告中注明。
• AUTO_PROCEED = true — 当值为 true 时，检查点仅用于告知：报告所选选项并在同一轮继续。设为 false 时，则要求用户明确确认，并在每个选择检查点结束本轮。
• REVIEWER_MODEL = gpt-6-astra — 通过 Codex MCP 使用的模型。对于 backend=codex，使用 OpenAI 模型（例如 gpt-6-astra、gpt-6.1-sol）。此值会传递给子技能。
• OUTPUT_DIR = idea-stage/ — 所有创意阶段的输出都放在此处。如果目录不存在，则创建该目录。
• ARXIV_DOWNLOAD = false — 当值为 true 时，/research-lit 会在阶段 1 下载最相关的 arXiv PDF。默认值 false 时仅获取元数据。此值会传递给 /research-lit。
• COMPACT = false — 当值为 true 时，为上下文较短的模型和会话恢复生成精简摘要文件。在此工作流结束时写入 idea-stage/IDEA_CANDIDATES.md（仅包含排名前 3～5 的创意）。下游技能会读取此文件，而非完整的 idea-stage/IDEA_REPORT.md。
• RENDER_HTML = true — 当值为 true（默认值）时，在工作流结束时通过 /render-html 自动将 idea-stage/IDEA_REPORT.md 渲染为 HTML。使用 --no-review（源 Markdown 已在阶段 3 经过新颖性审查和跨模型审查）。设为 false 可跳过，或传入 — render html: false。
• REF_PAPER = false — 用作创意基础的参考论文。接受：本地 PDF 路径、arXiv URL 或任意论文 URL。设置后会先对论文进行总结（idea-stage/REF_PAPER_SUMMARY.md），然后以其作为上下文生成创意。可与 base repo 搭配，用于“基于此代码库改进这篇论文”的工作流。
• RESUMABLE = true — 在 .aris/runs/<run_id>.json 下记录阶段证据，并要求通过确定性证据门槛后，才能将最终报告标记为完成。

💡 这些是默认值。可通过告知技能来覆盖，例如 /idea-discovery "topic" — ref paper: https://arxiv.org/abs/2406.04329 或 /idea-discovery "topic" — compact: true。

检查点执行规则

在 Phase 0 之前，根据 $ARGUMENTS 一次性确定 AUTO_PROCEED，并在整个工作流中保持该模式。

• AUTO_PROCEED=true 表示非阻塞。 检查点是进度更新，不是提问。说明结果和自动选定的下一步操作，然后在同一轮中继续执行。不要请求确认、要求用户输入、休眠、等待用户沉默，也不要在检查点结束本轮。
• AUTO_PROCEED=false 表示阻塞。 展示选项并询问用户，然后结束本轮。只有在用户明确回复后才能继续。

绝不要将自动继续实现为“先询问，如果没有回应再继续”。 一旦本轮结束，用户的沉默不能恢复工作流。用户仍可随时中断非阻塞运行。

此规则仅适用于由 AUTO_PROCEED 控制的选择检查点。如果用户明确启用了飞书的交互式关卡，则该外部审批或回复是有意设置的阻塞例外；应等待该由用户控制的关卡，而不要将其视为沉默超时。AUTO_PROCEED=true 时，飞书关闭或仅推送模式仍为非阻塞。

各阶段证据门控（RESUMABLE = true）

使用与 /research-pipeline 相同的规范辅助程序链解析 run_state.py 和 idea_discovery_gate.py：.aris/tools/ → tools/ → $ARIS_REPO/tools/ → ~/.aris/repo/tools/。如果任一辅助程序不可用，最终报告应为 BLOCKED；不要在没有状态记录的情况下悄然继续。

对于新运行，根据方向 slug 和日期生成 <run_id>，然后使用 --executor <actual-Claude-model>（例如，claude-sonnet-4.5）启动此有序状态记录：

research-lit,idea-creator,novelty-check,research-review,research-refine-pipeline

对于每个阶段，进入时标记为 running，仅在其产物存在后才标记为 done --artifact <path>。使用以下产物定位符，以便最终门控能够检查规范报告，而不是散落的临时文件：

阶段	产物定位符
research-lit	idea-stage/IDEA_REPORT.md#literature-landscape
idea-creator	idea-stage/IDEA_REPORT.md#ranked-ideas
novelty-check	idea-stage/IDEA_REPORT.md#novelty-verification
research-review	idea-stage/IDEA_REPORT.md#external-critical-review
research-refine-pipeline	refine-logs/FINAL_PROPOSAL.md

novelty-check 和 research-review 是包含审查者的阶段。done 状态或单独一个标题都不算审查证据。每个阶段将实质性发现纳入其锚定报告章节后，先记录为 done，然后仅在配置的审查者实际返回肯定且带身份标识的评定后，才使用实际返回的模型和持久化的线程/跟踪 ID 记录跨系列收据：

<resolved-python> <resolved-run_state.py> accept . <run_id> novelty-check --verdict-id "<thread-or-trace-id>" --reviewer "<actual-reviewer-model>"
<resolved-python> <resolved-run_state.py> accept . <run_id> research-review --verdict-id "<thread-or-trace-id>" --reviewer "<actual-reviewer-model>"

绝不可捏造任一值，也绝不可在没有运行状态契约要求的肯定评定时调用 accept。对于 novelty-check，PROCEED 和 PROCEED WITH CAUTION 都是肯定评定——谨慎是对试点的指导，并非拒绝；只有 ABANDON 是否定评定。对于 research-review，肯定意味着审查的结论没有主张放弃该想法——列出明确的风险并不等于拒绝。如果审查结束时没有明确立场，请在同一审查者线程中要求其给出一行评定（继续或放弃），并根据该答复记录；绝不可从沉默中推断为肯定。否定评定不会授予审查收据。将阶段保留为 done，并将最终门控设为 BLOCKED，然后选择一个仍可行的想法或新想法，再次运行该包含审查者的阶段。如果审查者不可用、没有返回有效身份/答复，或其输出未纳入报告，也应照此处理。

在第 5 阶段结束时，运行：

<resolved-python> <resolved-idea_discovery_gate.py> . <run_id> --report idea-stage/IDEA_REPORT.md

门控会将结果写入运行状态中的 gates.idea-discovery-evidence。若为 PASS，则表示已验证（但绝不会创建）两份审查收据、所有必需产物以及非空的锚定报告章节。各阶段的验收仍由各阶段自身的跨模型门控负责。若退出码非零，它会在报告中写入明确的 BLOCKED: <stage> evidence missing 行；不要将工作流表述为已完成。执行 — resume <run_id> 时，从第一个非终态阶段开始，并在最终完成前重新运行门控。

流水线

阶段 0：加载研究简报（如有）

开始任何其他阶段之前，请先检查项目中是否有详细的研究简报：

1. 在项目根目录（或 $ARGUMENTS 指定的路径）中查找 RESEARCH_BRIEF.md
2. 如果找到，请阅读并提取以下内容：
   • 问题陈述和背景
   • 限制条件（算力、数据、时间线、发表场所）
   • 用户已尝试的内容／未奏效的内容
   • 领域知识和非目标
   • 现有结果（如有）
3. 将其作为后续所有阶段的主要背景信息——它会取代单行提示词
4. 如果 RESEARCH_BRIEF.md 和单行 $ARGUMENTS 同时存在，请合并两者（简报优先提供细节，参数则确定方向）

如果没有简报，请将 $ARGUMENTS 作为研究方向，照常继续。

💡 使用模板创建简报：cp templates/RESEARCH_BRIEF_TEMPLATE.md RESEARCH_BRIEF.md——控制在约 1–2 页（4–8k 字符）；较长的材料请放入单独的文件，并通过路径引用。

阶段 0.5：参考论文摘要（设置了 REF_PAPER 时）

如果 REF_PAPER 为 false，则完全跳过。

在检索文献之前，先总结参考论文：

1. 如果是 arXiv URL（例如 https://arxiv.org/abs/2406.04329）：

   • 调用 /arxiv "ARXIV_ID" — download 获取 PDF
   • 阅读前 5 页（标题、摘要、引言、方法概述）

2. 如果是本地 PDF 路径（例如 papers/reference.pdf）：

   • 直接阅读 PDF（前 5 页）

3. 如果是其他 URL：

   • 通过 WebFetch 获取并提取内容

4. 生成 idea-stage/REF_PAPER_SUMMARY.md：

# Reference Paper Summary

**Title**: [paper title]
**Authors**: [authors]
**Venue**: [venue, year]

## What They Did
[2-3 sentences: core method and contribution]

## Key Results
[Main quantitative findings]

## Limitations & Open Questions
[What the paper didn't solve, acknowledged weaknesses, future work suggestions]

## Potential Improvement Directions
[Based on the limitations, what could be improved or extended?]

## Codebase
[If `base repo` is also set: link to the repo and note which parts correspond to the paper]

**🚦 检查点：**向用户展示摘要：

📄 Reference paper summarized:
- Title: [title]
- Key limitation: [main gap]
- Improvement directions: [2-3 bullets]

Proceeding to literature survey with this as context.

阶段 1 和阶段 2 将使用 idea-stage/REF_PAPER_SUMMARY.md 作为补充背景信息——/research-lit 会搜索相关及竞争性工作，/idea-creator 会生成以参考论文为基础或对其加以改进的想法。

阶段 1：文献调研

调用 /research-lit 梳理研究领域。创意探索正是 Gemini 的 AI 驱动广泛覆盖能够发挥价值的环节，因此默认将 gemini 作为信息来源，除非用户在创意探索调用中已明确指定 — sources: 指令：

# If $ARGUMENTS already contains "— sources:", pass through unchanged
# (the user is in control of source selection):
/research-lit "$ARGUMENTS" — composed: idea-stage/IDEA_REPORT.md

# Otherwise (the common case), include gemini explicitly for broader discovery:
/research-lit "$ARGUMENTS" — sources: all, gemini — composed: idea-stage/IDEA_REPORT.md

— composed: idea-stage/IDEA_REPORT.md 会使 /research-lit 进入组合模式（见上文 输出规范）：它会返回研究领域概览，供整合进报告，而不是单独写入一个领域概览文件。阶段 1 时报告尚不存在——此指令指定的是后续生成的规范文档，而 /idea-creator 会在阶段 2 创建该文档。

如果未安装 gemini-cli，/research-lit 会发出警告并正常跳过 Gemini 信息源，不会中断流程。想在创意探索中强制停用 Gemini 的用户，可显式传入 /idea-discovery "topic" — sources: all（这会成为字面意义上的信息源列表，不会自动注入其他来源）。

此操作会：

• 搜索 arXiv、Google Scholar、Semantic Scholar 上的近期论文
• 如果 gemini-cli 可用，还会借助 Gemini 进行广泛探索（分解子问题、变体命名、覆盖别名）
• 绘制研究领域图谱：子方向、方法、开放问题
• 找出结构性空白和反复出现的局限
• 输出文献摘要（保存至工作笔记）

**🚦 检查点：**向用户展示研究领域摘要。

**当 AUTO_PROCEED=true 时（非阻塞）：**报告选定的方向，并在同一轮中立即继续，不提问：

📚 Literature survey complete. Here's what I found:
- [key findings, gaps, open problems]

AUTO_PROCEED: selected [top-ranked direction]. Continuing to Phase 2.

**当 AUTO_PROCEED=false 时（阻塞）：**展示相同的研究结果，询问 Does this match your understanding? Should I adjust the scope before generating ideas?， 然后结束本轮。

• 用户批准 → 根据最佳方向进入阶段 2。
• 用户请求更改（例如“更多关注 X”“忽略 Y”“范围太广”）→ 使用更新后的查询细化搜索，以调整后的范围重新运行 /research-lit，并再次展示结果。重复此过程，直到用户满意。

第 2 阶段：创意生成 + 筛选 + 试点实验

使用领域背景调用 /idea-creator（如果有 idea-stage/REF_PAPER_SUMMARY.md，也一并提供）：

/idea-creator "$ARGUMENTS" — composed: idea-stage/IDEA_REPORT.md

/idea-creator 负责维护 idea-stage/IDEA_REPORT.md，将其作为规范交付物；— composed: 指令要求它纳入调研和新颖性研究结果，而不是另外生成 LIT_LANDSCAPE.md / RESEARCH_REVIEW.md / MANIFEST.md。

此操作的内容：

• 如果 idea-stage/REF_PAPER_SUMMARY.md 存在，将其纳入背景信息——创意应以参考论文为基础，在其上改进或扩展
• 使用 GPT-6-Astra xhigh 集思广益，提出 8-12 个具体创意
• 根据可行性、计算成本和快速新颖性检索结果进行筛选
• 对排名靠前的创意进行深入验证（全面的新颖性检查 + 反方审视）
• 在可用 GPU 上并行开展试点实验（排名前 2-3 的创意）
• 根据实证信号进行排序
• 输出 idea-stage/IDEA_REPORT.md

**🚦 检查点：**向用户展示按排名排列的 idea-stage/IDEA_REPORT.md 中的创意。

**当 AUTO_PROCEED=true 时（非阻塞）：**报告自动选择的创意，并立即在同一轮中继续，不要提问：

💡 Generated X ideas, filtered to Y, piloted Z. Top results:

1. [Idea 1] — Pilot: POSITIVE (+X%)
2. [Idea 2] — Pilot: WEAK POSITIVE (+Y%)
3. [Idea 3] — Pilot: NEGATIVE, eliminated

AUTO_PROCEED: selected [top-ranked idea(s)]. Continuing to Phase 3.

**当 AUTO_PROCEED=false 时（阻塞）：**展示相同的排名，并询问 我应该进一步验证哪些创意？或者要我根据不同的限制条件重新生成吗？， 然后结束本轮。

• 用户选择创意 → 使用选定的创意进入第 3 阶段。
• 用户对所有创意都不满意 → 收集反馈（“缺少什么？”“你更倾向于哪个方向？”），根据用户的限制条件更新提示词，并重新运行第 2 阶段（创意生成）。重新生成前，读取已经尝试过的方向（research-wiki Failed Ideas 和任何 .aris/runs/<run_id>.iterations.jsonl），并禁止提出与已尝试方向过于接近的候选创意——确保方向多样性；如果运行由隔夜心跳驱动，则通过 iteration_log.py note ... --direction "<frame>" 记录每个选定方向，以便后续轮次排除近似重复项（参见 shared-references/external-cadence.md → Stall detection & forced structural pivot）。重复此过程，直到用户至少选择 1 个创意。
• 用户想调整范围 → 回到第 1 阶段，细化方向。

第 3 阶段：深入新颖性验证

针对每个排名靠前的创意（试点信号为正），进行全面的新颖性检查：

/novelty-check "[top idea 1 description]"
/novelty-check "[top idea 2 description]"

此操作的内容：

• 多来源文献检索（arXiv、Scholar、Semantic Scholar）
• 使用 GPT-6-Astra xhigh 交叉验证
• 检查近期工作（过去 3-6 个月）
• 找出最接近的现有工作和差异化之处

更新 idea-stage/IDEA_REPORT.md，加入深入的新颖性研究结果。剔除任何最终发现已经发表的创意。

第 4 阶段：外部严格评审

针对筛选后保留的排名靠前的创意，获取犀利的外部评估——包括最有力的论据、明确列出的风险，以及成本最低且能区分不同结果的下一项实验；不得重写核心假设：

/research-review "[top idea with hypothesis + pilot results]" — composed: idea-stage/IDEA_REPORT.md

在组合模式下，/research-review 会将其结论纳入 idea-stage/IDEA_REPORT.md，并引用 .aris/traces/… 路径，而不是在项目根目录中单独编写评审 .md 文件。

此操作的内容：

• GPT-6-Astra xhigh 担任资深评审（NeurIPS/ICML 级别）
• 对创意评分、指出弱点并提出最低限度的改进建议
• 针对实验设计提供具体反馈

更新 idea-stage/IDEA_REPORT.md，加入评审意见和修订后的计划。

阶段 4.5：方法改进 + 实验规划

评审后，将最优想法完善为具体提案，并规划实验：

/research-refine-pipeline "[top idea description + pilot results + reviewer feedback]"

此步骤的作用：

• 锁定 问题锚点，防止范围偏移
• 通过 GPT-6-Astra 评审来改进方法——评审者指出的风险用于选择下一步测试，而不是添加组件；评分仅供参考，保留核心假设比迎合评审者更重要
• 制定以主张为导向的实验路线图，包含消融实验、预算和运行顺序
• 输出：refine-logs/FINAL_PROPOSAL.md、refine-logs/EXPERIMENT_PLAN.md、refine-logs/EXPERIMENT_TRACKER.md

🚦 检查点： 展示改进后的提案摘要。

当 AUTO_PROCEED=true 时（非阻塞）： 报告提案已选定，并在同一轮中立即继续，不提问：

🔬 Method refined and experiment plan ready:
- Problem anchor: [anchored problem]
- Method thesis: [one sentence]
- Dominant contribution: [what's new]
- Must-run experiments: [N blocks]
- First 3 runs to launch: [list]

AUTO_PROCEED: accepted the top proposal. Continuing to Final Report.

当 AUTO_PROCEED=false 时（阻塞）： 展示相同的摘要，询问 Proceed to implementation? Or adjust the proposal?，然后结束本轮。

• 用户批准 → 继续生成最终报告。
• 用户要求修改 → 将反馈交给 /research-refine，进行新一轮改进。
• 精简模式： 如果试点实验没有定论，仍须制定最精简、能够区分不同假设的下一步实验计划——不能仅凭评审者评分降低某个想法的优先级。

阶段 5：最终报告

根据所有累积信息，完成 idea-stage/IDEA_REPORT.md：

# Idea Discovery Report

**Direction**: $ARGUMENTS
**Date**: [today]
**Pipeline**: research-lit → idea-creator → novelty-check → research-review → research-refine-pipeline

## Executive Summary
[2-3 sentences: best idea, key evidence, recommended next step]

## Literature Landscape
[from Phase 1]

## Ranked Ideas
[from Phase 2, updated with Phase 3-4 results]

## Novelty Verification
[from Phase 3]

## External Critical Review
[from Phase 4]

### 🏆 Idea 1: [title] — RECOMMENDED
- Pilot: POSITIVE (+X%)
- Novelty: CONFIRMED (closest: [paper], differentiation: [what's different])
- Reviewer score: X/10
- Next step: implement full experiment → /auto-review-loop

### Idea 2: [title] — BACKUP
...

## Eliminated Ideas
[ideas killed at each phase, with reasons]

## Refined Proposal
- Proposal: `refine-logs/FINAL_PROPOSAL.md`
- Experiment plan: `refine-logs/EXPERIMENT_PLAN.md`
- Tracker: `refine-logs/EXPERIMENT_TRACKER.md`

## Next Steps
- [ ] /run-experiment to deploy experiments from the plan
- [ ] /auto-review-loop to iterate until submission-ready
- [ ] Or invoke /research-pipeline for the complete end-to-end flow

在将此报告标记为完整之前，先运行上述分阶段证据检查关卡。BLOCKED 检查结果应作为报告的一部分，而不是需要省略的警告。

阶段 5.5：编写精简文件（当 COMPACT = true 时）

如果 COMPACT 为 false，则完全跳过。

编写 idea-stage/IDEA_CANDIDATES.md，简要总结排名前 3-5 的存续想法：

# Idea Candidates

| # | Idea | Pilot Signal | Novelty | Reviewer Score | Status |
|---|------|-------------|---------|---------------|--------|
| 1 | [title] | +X% | Confirmed | X/10 | RECOMMENDED |
| 2 | [title] | +Y% | Confirmed | X/10 | BACKUP |
| 3 | [title] | Negative | — | — | ELIMINATED |

## Active Idea: #1 — [title]
- Hypothesis: [one sentence]
- Key evidence: [pilot result]
- Next step: /experiment-bridge or /research-refine

此文件有意保持精简（约 30 行），以便下游技能和会话恢复流程无需加载完整的 idea-stage/IDEA_REPORT.md（200 多行）即可读取。

阶段 5.6：建立研究契约（始终执行——不受 COMPACT 限制）

当阶段 4 结束时有一个 RECOMMENDED 想法，应根据 templates/RESEARCH_CONTRACT_TEMPLATE.md 创建 idea-stage/docs/research_contract.md（从仓库根目录或 $ARIS_REPO/templates/ 查找该模板），并填写：选定的想法及选择理由、核心主张、最低限度的有说服力的证据，以及下一步指引。仅当本次运行没有产生 RECOMMENDED 想法时才跳过。

此文件是 W1 → W1.5 交接的聚焦工作契约： /experiment-bridge 根据它进行实施，/result-to-claim + /ablation-planner 将其作为主张来源。它也是会话恢复文件中的第 2 号文件（docs/SESSION_RECOVERY_GUIDE.md）——会话崩溃后，会从此契约中重新加载当前 ACTIVE 想法，而不是完整的想法池。

输出协议

对所有输出文件遵循以下通用协议：

• 输出内容编排协议 — 每条流水线只保留一个规范交付物；将子技能的发现整合其中，不要散落互相重叠的 .md 文件
• 输出版本控制协议 — 先写入带时间戳的文件，再复制到固定名称的文件
• 输出清单协议 — 仅当产物超过 15 项的阈值时维护 MANIFEST.md（而不是“记录每项输出”）
• 输出语言协议 — 遵循项目的语言设置

输出规范——仅保留一份规范文档，不生成重复的 MD 文件（必需）

此流水线以组合模式运行其子技能（参见 output-composition.md）：它负责维护一份规范交付物，并将每个子技能的发现汇总到其中，而不是让每个子技能都生成内容重叠的文件。具体来说，对于此工作流：

1. idea-stage/IDEA_REPORT.md 是唯一的规范交付物。 子技能的中间发现（文献概况、新颖性说明、外部评审）应作为章节／附录汇总到其中——不能仅仅因为某个子技能可以生成独立文件，就把这些内容单独存为文件。如果子技能写入了临时文件，应将其中独有的内容纳入报告，并在该阶段结束时删除临时文件。
2. 向每个子技能传递 — composed: idea-stage/IDEA_REPORT.md（/research-lit、 /idea-creator、/research-review），让它们汇总内容，而不是分散输出。这是明确的信号；如果没有此信号，子技能会按设计独立输出。
3. 精炼方法的输出保留在 refine-logs/ 中（FINAL_PROPOSAL.md／ EXPERIMENT_PLAN.md／EXPERIMENT_TRACKER.md）。不要再在 idea-stage/ 下为它们另建独立文件；报告应当链接到这些文件，而不是复制其内容。
4. 文件数量不多时，不要创建 MANIFEST.md——只有超过 15 个产物时，才根据 output-manifest.md 创建。
5. **试点临时文件可删除：**保留试点脚本（可重复使用）和一个结果文件 （pilot_results.jsonl 或简短摘要）即可。数据录入报告后，删除启动器日志、冒烟测试文件和多余的 *_summary.json。
6. 跨模型评审记录应存放在 .aris/traces/…（审计轨迹）中；不要在 idea-stage/ 下再保留一份供人阅读的副本——在报告中引用记录路径即可。
7. 完成前，idea-stage/ 顶层应大致包含：IDEA_REPORT.md （+ .html）、试点脚本和结果，以及 refine-logs/ 目录。除非其他文件包含报告中没有的内容，否则不要保留。

渲染 HTML 视图（RENDER_HTML = true 时自动执行）

第 4 阶段完成 idea-stage/IDEA_REPORT.md（以及可选的 IDEA_CANDIDATES.md）后，对报告调用 /render-html，以便用户在平板电脑／手机上阅读单文件 HTML 视图：

/render-html "idea-stage/IDEA_REPORT.md" --no-review

--no-review 是有意设置的：源 MD 已通过此技能自身的新颖性审查和跨模型评审。HTML 渲染是结构转换，不是新的主张审查关卡。输出位于 idea-stage/IDEA_REPORT.html，其中嵌入了源文件 SHA256 和渲染时间戳。

**不阻塞流程：**如果 /render-html 失败（缺少辅助工具、Codex MCP 不可用、文件写入错误），记录失败并继续——HTML 视图只是便利性产物，并非第 4 阶段的前置条件。

如果 RENDER_HTML = false，则跳过此步骤。

关键规则

• 处理大文件：如果 Write 工具因文件过大而失败，请立即改用 Bash（cat << 'EOF' > file）分块写入。不要征求用户许可——直接静默执行。

• 不要跳过阶段。 每个阶段都会筛选和验证；跳过阶段会导致后续白费功夫。

• 在阶段之间设置检查点。 简要总结发现。若 AUTO_PROCEED=true，说明选定的下一步操作，并在同一轮中继续执行；若为 false，则提出询问并结束本轮。

• 让试点决定是否终止，不要凭感觉。 一个结论为否的低成本试点，胜过一个实现了一个月才得出否定结论的项目——但终止决定必须有实证信号或具名的已发表论文作为依据，而非个人喜好。只在纸面上自我说服放弃想法，会让流水线最终无事可做。

• 实证信号 > 理论吸引力。 有正面试点结果的想法，优先于“听起来很棒”但没有证据的想法。

• 记录一切——都写在同一份报告中，不要分散到多个文件。 失败的方向和被淘汰的想法都很有价值，请将它们作为 idea-stage/IDEA_REPORT.md 中的章节记录（见上文的 输出规范）。不要为每个阶段另建一个 .md 文件。

• 如实告知审阅者。 在审阅提示词中包含负面结果和失败的试点。

• 飞书通知为可选项。 如果 ~/.claude/feishu.json 存在，请在每次阶段转换时发送 checkpoint，并在最终报告完成时发送 pipeline_done。如果文件不存在或已关闭，则静默跳过。

与工作流 2 配合使用

此流水线产出经过验证的首选想法后：

/idea-discovery "direction"         ← you are here (Workflow 1, includes method refinement + experiment planning)
/run-experiment                     ← deploy experiments from the plan
/auto-review-loop "top idea"        ← Workflow 2: iterate until submission-ready

Or use /research-pipeline for the full end-to-end flow.