research-review

通过外部审阅后端进行研究审查（超强推理）

🔒 **请勿将此技能封装在 /loop、/schedule 或 CronCreate 中。**它会给出裁定结果——生成跨模型审查结论，并进行多轮审查，保持审阅者线程连续性。外部计时器会按实际时间重新触发裁定，破坏审阅者跨轮次的记忆：没有任何新信息，却要付出全部 Token 成本。请安排前置的外部等待（工作准备就绪 → 然后审查一次），而不是安排裁定本身。参见 shared-references/external-cadence.md。

使用所选的外部审阅后端，以最大推理深度对研究工作进行多轮严格审查。

常量

• REVIEWER_MODEL = gpt-6-astra — Codex 后端的默认模型，推理强度为 ultra（深度审计级）。必须是 OpenAI 模型（例如 gpt-6-astra、gpt-6.1-sol）。手动后端使用用户选择的模型，且必须是来自不同家族的已知模型（OpenAI、Anthropic、Google、DeepSeek、Moonshot/Kimi、Qwen）。
• REVIEWER_BACKEND = codex — 默认值：Codex MCP（ultra）。依照 reviewer-backends.md，使用 reviewer_route.py（--host claude-code --tier deep）依次解析 — reviewer:、项目 .aris/reviewer.json，然后采用此默认值。Gemini/Antigravity、Grok 和 Claude Code 在下方每次调用时均遵循此约定。旧版 Oracle/手动约定仍保留在 reviewer-routing.md 中；所选路由不可用时，不会静默回退。

审阅者调用约定

调用审阅者时，根据 REVIEWER_BACKEND 选择分支：

如果 REVIEWER_BACKEND ∈ {antigravity, grok, claude-code}： 按照 reviewer-backends.md 中所选的首次调用/回复协议，使用相同的审查提示词、包含主要文件的明确 cwd，以及解析出的特定提供方模型/推理强度。保存路由、cwd 和会话 ID，以便继续审查。 Claude Code 桥接程序可能运行 DeepSeek；请根据其报告的模型确定模型家族。

如果 REVIEWER_BACKEND = codex： 新审查线程使用 mcp__codex__codex。 后续轮次使用 mcp__codex__codex-reply（复用 threadId）。

如果 REVIEWER_BACKEND = manual： 新审查线程使用 mcp__manual_review__review，并提供： prompt：[与发送给 Codex 的提示词完全相同] config: {"model_reasoning_effort": "xhigh", "executor_model": "", "require_reviewer_model": true} 保存返回的 threadId。 后续轮次使用 mcp__manual_review__review_reply，并提供： threadId：[已保存的手动审查 threadId] prompt：[后续提示词] config: {"model_reasoning_effort": "xhigh", "executor_model": "", "require_reviewer_model": true}

内容保真度：手动审阅者应看到与 Codex 相同的实质性审查简报。如果手动界面支持文件上传/附件，请复用同一份简报文件；否则，将简报内容直接粘贴进去，因为远程 Web 界面无法读取本地文件系统路径。两种后端均适用审查追踪。

上下文：$ARGUMENTS

先决条件

• 所选 MCP 必须可用。对于默认的 Codex MCP Server：

  claude mcp add codex -s user -- python3 "$HOME/aris_repo/mcp-servers/codex-exec/server.py"   # your ARIS clone's path
  

• 这使 Claude Code 能够使用 mcp__codex__codex 和 mcp__codex__codex-reply 工具

工作流

第 1 步：收集研究背景

调用外部审阅者前，先整理一份全面的简报：

1. 阅读项目叙述文档（例如 STORY.md、README.md、论文草稿）
2. 阅读记忆/笔记文件，了解关键发现和实验历史
3. 明确：核心主张、方法、关键结果和已知弱点

第 2 步：初步审查（第 1 轮）

使用选定的后端发送详细的提示词，并启用超强推理。对于 codex 后端，请保持 MCP 载荷简短：将完整简报写入 RESEARCH_REVIEW_REQUEST.md，然后让 Codex 查看该文件。

对于 codex 后端：

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "ultra"}
  prompt: |
    Read the review brief at <absolute path to RESEARCH_REVIEW_REQUEST.md>.
    Executor notes are not evidence beyond the files they cite, so verify the
    referenced artifacts before judging.
    Please act as a senior ML reviewer (NeurIPS/ICML level). Start from the
    assumption that the work is broken somewhere — your job is to find where.
    Be adversarial. Trust nothing the author tells you — verify everything
    yourself. Identify:
    1. Logical gaps or unjustified claims
    2. Missing experiments that would strengthen the story
    3. Narrative weaknesses
    4. Whether the contribution is sufficient for a top venue

    === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
    Report anything that is actually wrong here — including a rare-looking case, if
    this repo actually produces it. Then keep the fix in scope:
    1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
       welcome; over-defense is not. Assume a cooperating operator on their own
       machine — a malicious local user is NOT in the threat model.
    2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
       Reporting a real defect in hashing code that already exists is fine.
    3. NO speculative machinery: do not add feature flags, migration frameworks,
       compat layers, wrappers, pins, or similar mechanisms unless evidence shows
       a current repo defect they fix or an explicit existing invariant they must
       preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
       not evidence. Point to the failing path/artifact or invariant, and check the
       proposal's factual premises, such as whether a named package version exists.
    4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
       millisecond races are out of scope unless you can show the case arises here.
    5. Where a rubric or checklist is genuinely needed, do not over-mechanize
       judgement. A clear sentence a human reads beats a scored table nobody
       maintains.
    Exception: code that runs remote commands, starts a network service, or installs
    an MCP server runs on the user's machine with their credentials — trust-boundary
    findings there are in scope and the default is strict.
    Say plainly when something is correct. Do not manufacture findings.
    Be brutally honest. If, after genuinely trying to break it, the work
    holds up and is ready, say so clearly.

对于 Antigravity、Grok 或 Claude Code，请通过其选定的首次调用工具发送相同的提示词；不要将 Codex 的 config 复制到其他工具中。在解读响应之前，先检查是否成功完成，以及实际文件覆盖范围。

审查简报应包含完整的研究背景、具体问题，以及审查者应查看的主要产物／原始结果路径。

对于 manual 后端： 使用 mcp__manual_review__review 并提供相同内容的简报。如果手动审查界面支持附件，请附上 RESEARCH_REVIEW_REQUEST.md；否则，请直接粘贴简报。保存返回的 threadId。

第 3 步：迭代对话（第 2 至 N 轮）

对于 codex 后端：使用返回的 threadId 调用 mcp__codex__codex-reply。 对于 manual 后端：使用相同的 threadId 调用 mcp__manual_review__review_reply。 对于 Antigravity、Grok 或 Claude Code：遵循 reviewer-backends.md 中已保存路由的续接协议；保持其模型／cwd，并在 Claude 中重复指定 cwd／tools。 使用适当的工具继续对话。对于 Codex 后续轮次，请编写更新后的简报，例如 RESEARCH_REVIEW_ROUND_2.md，并且只发送路径：

mcp__codex__codex-reply:
  threadId: [saved reviewer threadId from Step 2]
  # replies inherit the thread's model/effort (gpt-6-astra ultra)
  prompt: |
    Read the updated review brief at <absolute path to
    RESEARCH_REVIEW_ROUND_2.md>.
    Focus on unresolved weaknesses and whether the revision actually fixed them.

对于手动后续轮次，如果可能，请附上同一份更新后的简报；否则，请直接粘贴简报。

每轮：

1. 回应 批评，并提供证据／反驳理由
2. 提出有针对性的后续问题，聚焦最具可操作性的要点
3. 索取具体交付物：实验设计、论文大纲、主张矩阵

关键后续提问模式：

• “如果我们将 X 重新表述为 Y，你的评估会改变吗？”
• “要回应对 Z 的担忧，最少需要做什么实验？”
• “请设计一套最小化的额外实验方案（每个 GPU 周带来的接收概率提升最高）”
• “请撰写一份带评分的模拟 NeurIPS/ICML 审稿意见”
• “请根据可能的实验结果，给出结果到主张的对应矩阵”

第 4 步：达成共识

满足以下条件时停止迭代：

• 双方就核心主张及其证据要求达成一致
• 确定了具体的实验计划
• 叙事结构已敲定

第 5 步：记录所有内容

将完整的互动和结论保存到项目根目录中的审查文档：

• 按轮次总结批评和回应
• 关于主张、叙事和实验的最终共识
• 主张矩阵（在每种可能结果下允许提出哪些主张）
• 按优先级排列的待办清单及预估计算成本
• 如有讨论，附上论文大纲

将关键审查结论更新到项目记忆／笔记中。

组合模式 — 如果调用时使用 — composed: <canonical-report-path>（例如 /idea-discovery 这样的编排器会传入此参数），则不要在项目根目录中单独编写审查 .md 文件。原始对话已保存至 .aris/traces/…（见下文 审查追踪；该审计副本在所有模式下都会保留）；请将审查结论（共识、主张矩阵、优先级待办事项）纳入编排器的规范报告，并在其中引用追踪路径。**默认情况（没有 — composed: 指令）：请严格按上述方式执行，编写单独的审查文档。**不得仅因报告文件已存在就推断为组合模式。完整规则见： shared-references/output-composition.md。

关键规则

• 对于默认的 Codex 路由，固定使用 model: gpt-6-astra + config: {"model_reasoning_effort": "ultra"}（深度审计等级；能力回退遵循 reviewer-routing.md，绝不低于 xhigh）。其他选定路由使用其解析出的模型／effort。
• 对于 manual，使用上方包含身份信息的配置。工具字段属于各自提供方的契约；不要在不同桥接之间复制载荷。
• 在评审简报中提供全面的上下文。传入绝对路径时，Codex 可以读取本地文件；手动评审者通常无法读取，因此也要在那里附上或粘贴同一份简报。
• 如实说明弱点——隐瞒弱点会导致更差的反馈
• 对你不同意的批评提出异议，但接受合理的意见
• 聚焦于可执行的反馈——“什么实验可以解决这个问题？”
• 记录 threadId，以便日后可能恢复会话
• 评审文档应自成一体（无需阅读对话即可理解）

提示词模板

初始评审：

“我将提交一个完整的 ML 研究项目，请你进行严格评审。请以资深 ML 评审者（NeurIPS/ICML 级别）的身份……”

实验设计：

“请设计一套最精简的补充实验，以每 GPU 周计算量换取最高的录用率提升。我们的计算资源：[描述]。请具体说明配置。”

论文结构：

“请将其整理成具体的论文大纲，逐节列出论点并规划图表。”

论点矩阵：

“请提供一份结果到论点的矩阵：在实验 X 和 Y 的各种可能结果下，允许提出哪些论点？”

模拟评审：

“请撰写一份模拟的 NeurIPS 评审，包含：摘要、优点、缺点、给作者的问题、评分、信心，以及哪些改进会提高录用可能性。”

评审追踪

每次调用评审者后，都要按照 shared-references/review-tracing.md（Policy C — 取证；绝不静默跳过）保存追踪记录。记录所选路由／会话／cwd、请求和报告的模型、实际 effort、原始响应、完成情况和范围、结论、独立性，以及是否采纳，具体遵循 reviewer-backends.md。使用 save_trace.sh（根据 shared-references/integration-contract.md §2 中的链路解析），或直接将文件写入 .aris/traces/<skill>/<date>_run<NN>/。遵守 --- trace: 参数（默认值：full）。 任何包含结论的手动响应都必须以 Reviewer-Model: <exact-model-id> 开头——将本会话实际运行的模型作为 executor_model 传入。身份缺失、未知或属于同一模型系列都不能作为免责依据；应输出 REVIEW_UNAVAILABLE，而不是猜测。如果无法确定 executor 模型，则无法证实手动评审的跨系列声明——应在报告中说明这一点，而不是断言该声明。