rebuttal

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Workflow 4: Rebuttal

工作流4：反驳回复

Prepare and maintain a grounded, venue-compliant rebuttal for: $ARGUMENTS

为以下内容准备并维护符合会议要求、有依据的反驳回复：$ARGUMENTS

Scope

适用范围

This skill is optimized for:

ICML-style text-only rebuttal
strict character limits
multiple reviewers
follow-up rounds after the initial rebuttal
safe drafting with no fabrication, no overpromise, and full issue coverage

This skill does not:

run new experiments automatically
generate new theorem claims automatically
edit or upload a revised PDF
submit to OpenReview / CMT / HotCRP

If the user already has new results, derivations, or approved commitments, the skill can incorporate them as user-confirmed evidence.

本技能针对以下场景优化：

ICML风格的纯文本反驳回复
严格的字符限制
多位审稿人
初始反驳回复后的后续回合
无编造、不夸大承诺、覆盖所有问题的安全撰写

本技能不支持：

自动运行新实验
自动生成新定理声明
编辑或上传修订版PDF
向OpenReview / CMT / HotCRP提交回复

如果用户已有新结果、推导过程或已获批的承诺，本技能可将其作为用户确认的证据纳入回复。

Lifecycle Position

生命周期定位

text

Workflow 1:   idea-discovery
Workflow 1.5: experiment-bridge
Workflow 2:   auto-review-loop (pre-submission)
Workflow 3:   paper-writing
Workflow 4:   rebuttal (post-submission external reviews)

text

Workflow 1:   idea-discovery
Workflow 1.5: experiment-bridge
Workflow 2:   auto-review-loop (pre-submission)
Workflow 3:   paper-writing
Workflow 4:   rebuttal (post-submission external reviews)

Constants

常量配置

VENUE =
ICML
— Default venue. Override if needed.
RESPONSE_MODE =
TEXT_ONLY
— v1 default.
REVIEWER_MODEL =
gpt-5.4
— Used via Codex MCP for internal stress-testing.
REVIEWER_BACKEND =
codex
— Default: Codex MCP (xhigh). Override with
```
— reviewer: oracle-pro
```
for GPT-5.4 Pro via Oracle MCP. See
```
shared-references/reviewer-routing.md
```
.
MAX_INTERNAL_DRAFT_ROUNDS = 2 — draft → lint → revise.
MAX_STRESS_TEST_ROUNDS = 1 — One Codex MCP critique round.
MAX_FOLLOWUP_ROUNDS = 3 — per reviewer thread.
AUTO_EXPERIMENT = false — When
```
true
```
, automatically invoke
```
/experiment-bridge
```
to run supplementary experiments when the strategy plan identifies reviewer concerns that require new empirical evidence. When
```
false
```
(default), pause and present the evidence gap to the user for manual handling.
QUICK_MODE = false — When
```
true
```
, only run Phase 0-3 (parse reviews, atomize concerns, build strategy). Outputs
```
ISSUE_BOARD.md
```
+
```
STRATEGY_PLAN.md
```
and stops — no drafting, no stress test. Useful for quickly understanding what reviewers want before deciding how to respond.
REBUTTAL_DIR =
rebuttal/

Override:

/rebuttal "paper/" — venue: NeurIPS, character limit: 5000

VENUE =
ICML
— 默认会议。可按需覆盖。
RESPONSE_MODE =
TEXT_ONLY
— v1版本默认设置。
REVIEWER_MODEL =
gpt-5.4
— 通过Codex MCP用于内部压力测试。
REVIEWER_BACKEND =
codex
— 默认：Codex MCP（xhigh级别）。可通过
```
— reviewer: oracle-pro
```
参数覆盖为Oracle MCP提供的GPT-5.4 Pro。详见
```
shared-references/reviewer-routing.md
```
。
MAX_INTERNAL_DRAFT_ROUNDS = 2 — 撰写草稿 → 检查 → 修订。
MAX_STRESS_TEST_ROUNDS = 1 — 一轮Codex MCP评审。
MAX_FOLLOWUP_ROUNDS = 3 — 每位审稿人的回复线程最多3轮。
AUTO_EXPERIMENT = false — 设为
```
true
```
时，若策略计划识别到需要新实证证据的审稿人疑问，将自动调用
```
/experiment-bridge
```
运行补充实验。默认设为
```
false
```
时，将暂停流程并向用户展示证据缺口，由用户手动处理。
QUICK_MODE = false — 设为
```
true
```
时，仅运行0-3阶段（解析评审意见、拆分疑问、制定策略）。输出
```
ISSUE_BOARD.md
```
+
```
STRATEGY_PLAN.md
```
后停止，不进行草稿撰写和压力测试。适用于在决定如何回复前快速了解审稿人需求。
REBUTTAL_DIR =
rebuttal/

覆盖配置示例：

/rebuttal "paper/" — venue: NeurIPS, character limit: 5000

Required Inputs

必填输入

Paper source — PDF, LaTeX directory, or narrative summary
Raw reviews — pasted text, markdown, or PDF with reviewer IDs
Venue rules — venue name, character/word limit, text-only or revised PDF allowed
Current stage — initial rebuttal or follow-up round

If venue rules or limit are missing, stop and ask before drafting.

论文源文件 — PDF、LaTeX目录或内容摘要
原始评审意见 — 粘贴的文本、markdown格式文件或带审稿人ID的PDF
会议规则 — 会议名称、字符/字数限制、是否允许纯文本或修订版PDF
当前阶段 — 初始反驳回复或后续回合

若缺少会议规则或限制信息，停止流程并询问用户后再开始撰写。

Safety Model

安全校验模型

Three hard gates — if any fails, do NOT finalize:

Provenance gate — every factual statement maps to:
```
paper
```
,
```
review
```
,
```
user_confirmed_result
```
,
```
user_confirmed_derivation
```
, or
```
future_work
```
. No source = blocked.
Commitment gate — every promise maps to:
```
already_done
```
,
```
approved_for_rebuttal
```
, or
```
future_work_only
```
. Not approved = blocked.
Coverage gate — every reviewer concern ends in:
```
answered
```
,
```
deferred_intentionally
```
, or
```
needs_user_input
```
. No issue disappears.

三道严格校验关卡，任意一道不通过则不得定稿：

来源校验 — 每一项事实陈述必须对应：
```
论文原文
```
、
```
评审意见
```
、
```
用户确认的结果
```
、
```
用户确认的推导
```
或
```
未来工作
```
。无来源则被拦截。
承诺校验 — 每一项承诺必须对应：
```
已完成
```
、
```
获批用于反驳回复
```
或
```
仅作为未来工作
```
。未获批则被拦截。
覆盖校验 — 每一项审稿人疑问必须标记为：
```
已答复
```
、
```
有意推迟
```
或
```
需用户输入
```
。不得遗漏任何问题。

Workflow

工作流步骤

Phase 0: Resume or Initialize

阶段0：恢复或初始化

If
```
rebuttal/REBUTTAL_STATE.md
```
exists → resume from recorded phase
Otherwise → create
```
rebuttal/
```
, initialize all output documents
Load paper, reviews, venue rules, any user-confirmed evidence

若
```
rebuttal/REBUTTAL_STATE.md
```
存在 → 从记录的阶段恢复流程
否则 → 创建
```
rebuttal/
```
目录，初始化所有输出文档
加载论文、评审意见、会议规则及所有用户确认的证据

Phase 1: Validate Inputs and Normalize Reviews

阶段1：验证输入并标准化评审意见

Validate venue rules are explicit
Normalize all reviewer text into
```
rebuttal/REVIEWS_RAW.md
```
(verbatim)
Record metadata in
```
rebuttal/REBUTTAL_STATE.md
```
If ambiguous, pause and ask

验证会议规则是否明确
将所有审稿人文本标准化为
```
rebuttal/REVIEWS_RAW.md
```
（原文保留）
在
```
rebuttal/REBUTTAL_STATE.md
```
中记录元数据
若存在歧义，暂停流程并询问用户

Phase 2: Atomize and Classify Reviewer Concerns

阶段2：拆分并分类审稿人疑问

Create

rebuttal/ISSUE_BOARD.md

For each atomic concern:

```
issue_id
```
(e.g., R1-C2)
```
reviewer
```
,
```
round
```
,
```
raw_anchor
```
(short quote)
```
issue_type
```
: assumptions / theorem_rigor / novelty / empirical_support / baseline_comparison / complexity / practical_significance / clarity / reproducibility / other
```
severity
```
: critical / major / minor
```
reviewer_stance
```
: positive / swing / negative / unknown
```
response_mode
```
: direct_clarification / grounded_evidence / nearest_work_delta / assumption_hierarchy / narrow_concession / future_work_boundary
```
status
```
: open / answered / deferred / needs_user_input

创建

rebuttal/ISSUE_BOARD.md

文件。

针对每一个拆分后的疑问：

```
issue_id
```
（例如：R1-C2）
```
审稿人
```
、
```
回合
```
、
```
原文锚点
```
（简短引用）
```
问题类型
```
：假设 / 定理严谨性 / 创新性 / 实证支持 / 基线对比 / 复杂度 / 实际意义 / 清晰度 / 可复现性 / 其他
```
严重程度
```
：关键 / 主要 / 次要
```
审稿人立场
```
：正面 / 中立 / 负面 / 未知
```
回复模式
```
：直接澄清 / 有依据的证据 / 相近工作差异 / 假设层级 / 有限让步 / 未来工作边界
```
状态
```
：未处理 / 已答复 / 已推迟 / 需用户输入

Phase 3: Build Strategy Plan

阶段3：制定策略计划

Create

rebuttal/STRATEGY_PLAN.md

Identify 2-4 global themes resolving shared concerns
Choose response mode per issue
Build character budget (10-15% opener, 75-80% per-reviewer, 5-10% closing)
Identify blocked claims (ungrounded or unapproved)
If unresolved blockers → pause and present to user

QUICK_MODE exit: If

QUICK_MODE = true

, stop here. Present

ISSUE_BOARD.md

STRATEGY_PLAN.md

to the user and summarize: how many issues per reviewer, shared vs unique concerns, recommended priorities, and evidence gaps. The user can then decide to continue with full rebuttal (

/rebuttal — quick mode: false

) or write manually.

创建

rebuttal/STRATEGY_PLAN.md

文件。

确定2-4个全局主题以解决共性疑问
为每个问题选择回复模式
分配字符预算（开头占10-15%，每位审稿人回复占75-80%，结尾占5-10%）
识别受阻声明（无依据或未获批）
若存在未解决的受阻项 → 暂停流程并向用户展示

快速模式退出：若

QUICK_MODE = true

，在此阶段停止。向用户展示

ISSUE_BOARD.md

STRATEGY_PLAN.md

并总结：每位审稿人的问题数量、共性与独特疑问、推荐优先级及证据缺口。用户可选择继续完成完整反驳回复（

/rebuttal — quick mode: false

）或手动撰写。

Phase 3.5: Evidence Sprint (when AUTO_EXPERIMENT = true)

阶段3.5：证据补充（当AUTO_EXPERIMENT = true时）

Skip entirely if
AUTO_EXPERIMENT
is
false
— instead, pause and present the evidence gaps to the user.

If the strategy plan identifies issues that require new empirical evidence (tagged

response_mode: grounded_evidence

with

evidence_source: needs_experiment

Generate a mini experiment plan from the reviewer concerns:
- What to run (ablation, baseline comparison, scale-up, condition check)
- Success criterion (what result would satisfy the reviewer)
- Estimated GPU-hours

Invoke

/experiment-bridge

with the mini plan:

/experiment-bridge "rebuttal/REBUTTAL_EXPERIMENT_PLAN.md"

Wait for results, then update
```
ISSUE_BOARD.md
```
:
- Tag completed experiments as
```
user_confirmed_result
```
- Update evidence source for relevant issue cards
If experiments fail or are inconclusive:
- Switch response mode to
```
narrow_concession
```
  or
```
future_work_boundary
```
- Do NOT fabricate positive results
Save experiment results to
```
rebuttal/REBUTTAL_EXPERIMENTS.md
```
for provenance tracking.

Time guard: If estimated GPU-hours exceed rebuttal deadline, skip and flag for manual handling.

若
AUTO_EXPERIMENT
为
false
则完全跳过此阶段 — 改为暂停流程并向用户展示证据缺口。

若策略计划识别到需要新实证证据的问题（标记为

回复模式: 有依据的证据

且

证据来源: 需要实验

）：

根据审稿人疑问生成小型实验计划：
- 需运行的实验（消融实验、基线对比、规模扩展、条件验证）
- 成功标准（何种结果能满足审稿人）
- 预估GPU时长

调用

/experiment-bridge

并传入小型实验计划：

/experiment-bridge "rebuttal/REBUTTAL_EXPERIMENT_PLAN.md"

等待实验结果，然后更新
```
ISSUE_BOARD.md
```
：
- 将已完成的实验标记为
```
用户确认的结果
```
- 更新相关问题卡片的证据来源
若实验失败或结果不确定：
- 将回复模式切换为
```
有限让步
```
  或
```
未来工作边界
```
- 不得编造正面结果
将实验结果保存至
```
rebuttal/REBUTTAL_EXPERIMENTS.md
```
以追踪来源。

时间限制：若预估GPU时长超过反驳回复截止日期，跳过此阶段并标记为需手动处理。

Phase 4: Draft Initial Rebuttal

阶段4：撰写初始反驳回复草稿

Create

rebuttal/REBUTTAL_DRAFT_v1.md

Structure:

Short opener — thank reviewers + 2-4 global resolutions
Per-reviewer numbered responses — answer → evidence → implication
Short closing — resolved / remaining / acceptance case

Default reply pattern per issue:

Sentence 1: direct answer
Sentence 2-4: grounded evidence
Last sentence: implication for the paper

Heuristics from 5 successful rebuttals:

Evidence > assertion
Global narrative first, per-reviewer detail second
Concrete numbers for counter-intuitive points
Name closest prior work + exact delta for novelty disputes
Concede narrowly when reviewer is right
For theory: separate core vs technical assumptions
Answer friendly reviewers too

Hard rules:

NEVER invent experiments, numbers, derivations, citations, or links
NEVER promise what user hasn't approved
If no strong evidence exists, say less not more

Also generate

rebuttal/PASTE_READY.txt

(plain text, exact character count).

Also generate

rebuttal/REVISION_PLAN.md

— the overall revision checklist.

This document is the single source of truth for every paper revision promised (explicitly or implicitly) in the rebuttal draft. It exists so the author can track follow-through after the rebuttal is submitted, and so the commitment gate in Phase 5 has a concrete artifact to validate against.

Structure:

Header
- Paper title, venue, character limit, rebuttal round
- Links back to
```
ISSUE_BOARD.md
```
  ,
```
STRATEGY_PLAN.md
```
  ,
```
REBUTTAL_DRAFT_v1.md
```

Overall checklist — a single flat GitHub-style checklist covering every revision item, so the author can tick items off as they land in the camera-ready / revised PDF:

markdown

## Overall Checklist

- [ ] (R1-C2) Add assumption hierarchy table to Section 3.1 — commitment: `approved_for_rebuttal` — owner: author — status: pending
- [ ] (R2-C1) Clarify novelty delta vs. Smith'24 in Section 2 related work — commitment: `already_done` — status: verify wording
- [ ] (R3-C4) Add runtime breakdown figure to Appendix B — commitment: `future_work_only` — status: deferred, note in camera-ready
- ...

Checklist items must be atomic (one paper edit per line) and each must reference its

issue_id

so it maps back to

ISSUE_BOARD.md

Grouped view — the same items regrouped by (a) paper section/location and (b) severity, so the author can plan the revision pass efficiently.
Commitment summary — counts of
```
already_done
```
/
```
approved_for_rebuttal
```
/
```
future_work_only
```
, plus any
```
needs_user_input
```
items that are blocking.
Out-of-scope log — reviewer concerns that will not trigger a paper revision (e.g.
```
deferred_intentionally
```
,
```
narrow_concession
```
with no edit), with a one-line reason each. This keeps the checklist honest: nothing silently disappears.

Rules for

REVISION_PLAN.md

Every checklist item must map to at least one
```
issue_id
```
from
```
ISSUE_BOARD.md
```
.
Every promise in
```
REBUTTAL_DRAFT_v1.md
```
that implies a paper edit must appear as a checklist item — if it is not in the plan, it is a commitment-gate violation.
Never add items that are not backed by the draft or by user-confirmed evidence.
On rerun / follow-up rounds, update checkbox state in place rather than regenerating from scratch.

创建

rebuttal/REBUTTAL_DRAFT_v1.md

文件。

结构：

简短开头 — 感谢审稿人 + 2-4个全局解决方案
按审稿人分类的编号回复 — 答复 → 证据 → 对论文的影响
简短结尾 — 已解决问题 / 剩余问题 / 录用理由

每个问题的默认回复模板：

第1句：直接答复
第2-4句：有依据的证据
最后1句：对论文的影响

基于5次成功反驳回复总结的启发式规则：

证据 > 断言
先讲全局叙事，再讲针对每位审稿人的细节
对反直觉观点使用具体数据
提及最相近的前人工作 + 明确的创新性差异
当审稿人正确时做出有限让步
针对理论类问题：区分核心假设与技术假设
也要回复立场友好的审稿人

严格规则：

绝不能编造实验、数据、推导、引用或链接
绝不能做出用户未批准的承诺
若无有力证据，宁少勿多

同时生成

rebuttal/PASTE_READY.txt

（纯文本格式，精确字符数）。

同时生成

rebuttal/REVISION_PLAN.md

— 整体修订清单。

该文档是反驳回复草稿中所有明确或隐含承诺的论文修订事项的唯一权威来源。作者可在提交反驳回复后追踪落实情况，阶段5的承诺校验也需以此文档为依据。

结构：

页眉
- 论文标题、会议名称、字符限制、反驳回复回合
- 指向
```
ISSUE_BOARD.md
```
  、
```
STRATEGY_PLAN.md
```
  、
```
REBUTTAL_DRAFT_v1.md
```
  的链接

整体清单 — 一个扁平化的GitHub风格清单，涵盖所有修订事项，作者可在最终版/修订版PDF中完成后勾选：

markdown

## 整体清单

- [ ] (R1-C2) 在第3.1节添加假设层级表 — 承诺类型: `获批用于反驳回复` — 负责人: 作者 — 状态: 待处理
- [ ] (R2-C1) 在第2节相关工作中明确与Smith'24的创新性差异 — 承诺类型: `已完成` — 状态: 验证措辞
- [ ] (R3-C4) 在附录B添加运行时分解图 — 承诺类型: `仅作为未来工作` — 状态: 推迟，将在最终版中说明
- ...

清单事项必须原子化（每行对应一项论文修改），且每项必须引用其

issue_id

以关联

ISSUE_BOARD.md

。

分组视图 — 同一事项按(a)论文章节/位置和(b)严重程度重新分组，方便作者高效规划修订流程。

承诺汇总 —

已完成

获批用于反驳回复

仅作为未来工作

的数量统计，以及任何受阻的

需用户输入

事项。

超出范围记录 — 不会触发论文修订的审稿人疑问（例如：
```
有意推迟
```
、
```
无修改的有限让步
```
），每项需附带一行理由。确保清单真实准确：无事项被悄悄遗漏。

REVISION_PLAN.md

规则：

每一项清单事项必须至少关联
```
ISSUE_BOARD.md
```
中的一个
```
issue_id
```
。
```
REBUTTAL_DRAFT_v1.md
```
中所有隐含论文修改的承诺必须作为清单事项出现 — 若未列入计划，则违反承诺校验规则。
不得添加无草稿或用户确认证据支持的事项。
重新运行/后续回合时，直接更新复选框状态，而非从头生成。

Phase 5: Safety Validation

阶段5：安全校验

Run all lints:

Coverage — every issue maps to draft anchor
Provenance — every factual sentence has source
Commitment — promises are approved AND every paper-edit promise in the draft appears as a checklist item in
```
REVISION_PLAN.md
```
(and vice versa — no orphan items in the plan)
Tone — flag aggressive/submissive/evasive phrases
Consistency — no contradictions across reviewer replies
Limit — exact character count, compress if over (redundancy → friendly → opener → wording, never drop critical answers)

运行所有检查：

覆盖检查 — 每个问题都对应草稿中的锚点
来源检查 — 每一句事实陈述都有来源
承诺检查 — 承诺已获批，且草稿中所有涉及论文修改的承诺都已列入
```
REVISION_PLAN.md
```
的清单（反之亦然 — 清单中无孤立事项）
语气检查 — 标记攻击性/顺从性/回避性措辞
一致性检查 — 不同审稿人回复之间无矛盾
字数限制检查 — 精确字符数，若超出则压缩（优先删除冗余内容 → 友好性表述 → 开头 → 措辞，绝不能删除关键答复）

Phase 6: Codex MCP Stress Test

阶段6：Codex MCP压力测试

mcp__codex__codex:
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    Stress-test this rebuttal draft:
    [raw reviews + issue board + draft + venue rules]

    1. Unanswered or weakly answered concerns?
    2. Unsupported factual statements?
    3. Risky or unapproved promises?
    4. Tone problems?
    5. Paragraph most likely to backfire with meta-reviewer?
    6. Minimal grounded fixes only. Do NOT invent evidence.

    Verdict: safe to submit / needs revision

Save full response to

rebuttal/MCP_STRESS_TEST.md

. If hard safety blocker → revise before finalizing.

mcp__codex__codex:
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    对以下反驳回复草稿进行压力测试：
    [原始评审意见 + 问题看板 + 草稿 + 会议规则]

    1. 是否有未答复或答复薄弱的疑问？
    2. 是否有无依据的事实陈述？
    3. 是否有风险或未获批的承诺？
    4. 是否有语气问题？
    5. 最可能引起元审稿人反感的段落是哪一段？
    6. 仅提供基于依据的最小修改建议。不得编造证据。

    结论：可安全提交 / 需要修订

将完整回复保存至

rebuttal/MCP_STRESS_TEST.md

。若存在严重安全问题 → 修订后再定稿。

Phase 7: Finalize — Two Versions

阶段7：定稿 — 两个版本

Produce two outputs for different purposes:

rebuttal/PASTE_READY.txt
— the strict version
- Plain text, exact character count, fits venue limit
- Ready to paste directly into OpenReview / CMT / HotCRP
- No markdown formatting, no extras
rebuttal/REBUTTAL_DRAFT_rich.md
— the extended version
- Same structure but with more detail: fuller explanations, additional evidence, optional paragraphs
- Marked with
```
[OPTIONAL — cut if over limit]
```
  for sections that exceed the strict version
- Author can read this to understand the full reasoning, then manually decide what to keep/cut/rewrite
- Useful for follow-up rounds — the extra material is pre-written
Update
```
rebuttal/REBUTTAL_STATE.md
```
Refresh
```
rebuttal/REVISION_PLAN.md
```
so the overall checklist matches the final draft (add items, mark
```
already_done
```
as checked, carry forward any
```
pending
```
items)
Present to user:
- ```
PASTE_READY.txt
```
  character count vs venue limit
- ```
REBUTTAL_DRAFT_rich.md
```
  for review and manual editing
- ```
REVISION_PLAN.md
```
  checklist — counts of pending / approved / deferred
- Remaining risks + lines needing manual approval

生成两个输出版本以满足不同需求：

rebuttal/PASTE_READY.txt
— 精简版
- 纯文本格式，精确字符数，符合会议限制
- 可直接粘贴至OpenReview / CMT / HotCRP
- 无markdown格式，无额外内容
rebuttal/REBUTTAL_DRAFT_rich.md
— 扩展版
- 结构与精简版相同，但包含更多细节：更完整的解释、额外证据、可选段落
- 超出精简版的部分标记为
```
[可选 — 若超字数则删除]
```
- 作者可阅读此版本了解完整逻辑，再手动决定保留/删除/重写内容
- 适用于后续回合 — 额外内容已预先撰写
更新
```
rebuttal/REBUTTAL_STATE.md
```
更新
```
rebuttal/REVISION_PLAN.md
```
，使整体清单与最终草稿匹配（添加新事项，标记
```
已完成
```
为已勾选，更新现有事项的状态）
向用户展示：
- ```
PASTE_READY.txt
```
  的字符数与会议限制对比
- ```
REBUTTAL_DRAFT_rich.md
```
  供审核和手动编辑
- ```
REVISION_PLAN.md
```
  清单 — 待处理/已获批/已推迟事项的数量统计
- 剩余风险 + 需要手动批准的内容

Phase 8: Follow-Up Rounds

阶段8：后续回合

When new reviewer comments arrive:

Append verbatim to
```
rebuttal/FOLLOWUP_LOG.md
```
Link to existing issues or create new ones
Draft delta reply only (not full rewrite)
Update
```
rebuttal/REVISION_PLAN.md
```
in place — add any new checklist items introduced by the follow-up, tick off items the author has already completed, and keep existing items' status current
Re-run safety lints
Use Codex MCP reply for continuity if useful
Rules: escalate technically not rhetorically; concede if reviewer is correct; stop arguing if reviewer is immovable and no new evidence exists

当收到新的审稿人意见时：

将原文追加至
```
rebuttal/FOLLOWUP_LOG.md
```
关联现有问题或创建新问题
仅撰写增量回复（无需重写完整内容）
直接更新
```
rebuttal/REVISION_PLAN.md
```
— 添加后续回合引入的新清单事项，勾选作者已完成的事项，更新现有事项的状态
重新运行安全检查
若有用，使用Codex MCP回复以保持连续性
规则：侧重技术层面而非修辞层面；若审稿人正确则让步；若审稿人立场坚定且无新证据则停止争论

Key Rules

核心规则

Large file handling: If Write fails, retry with Bash heredoc silently.
Never fabricate. No invented evidence, numbers, derivations, citations, or links.
Never overpromise. Only promise what user explicitly approved.
Full coverage. Every reviewer concern tracked and accounted for.
Preserve raw records. Reviews and MCP outputs stored verbatim.
Global + per-reviewer structure. Shared concerns in opener.
Answer friendly reviewers too. Reinforce supportive framing.
Meta-reviewer closing. Summarize resolved/remaining/why accept.
Evidence > rhetoric. Derivations and numbers over prose.
Concede selectively. Narrow honest concessions > broad denials.
Don't waste space on unwinnable arguments. Answer once, move on.
Respect the limit. Character budget is a hard constraint.
Resume cleanly. Continue from REBUTTAL_STATE.md on rerun.
Anti-hallucination citations. Any reference added must go through DBLP → CrossRef → [VERIFY].

大文件处理：若写入失败，自动使用Bash heredoc重试。
绝不编造：不得编造证据、数据、推导、引用或链接。
绝不夸大承诺：仅做出用户明确批准的承诺。
全面覆盖：追踪并处理每一项审稿人疑问。
保留原始记录：评审意见和MCP输出原文保留。
全局+按审稿人分类的结构：共性疑问放在开头。
也要回复立场友好的审稿人：强化支持性表述。
元审稿人导向的结尾：总结已解决/剩余问题及录用理由。
证据 > 修辞：优先使用推导和数据而非文字表述。
选择性让步：有限的诚实让步 > 宽泛的否认。
不浪费篇幅在无意义的争论上：答复一次后即转移话题。
遵守字数限制：字符预算是硬性约束。
无缝恢复：重新运行时从
```
REBUTTAL_STATE.md
```
记录的阶段继续。
防幻觉引用：添加的任何参考文献必须经过DBLP → CrossRef → [验证]流程。

Review Tracing

评审追踪

After each

mcp__codex__codex

mcp__codex__codex-reply

reviewer call, save the trace following

shared-references/review-tracing.md

. Use

tools/save_trace.sh

or write files directly to

.aris/traces/<skill>/<date>_run<NN>/

. Respect the

--- trace:

parameter (default:

full

每次调用

mcp__codex__codex

或

mcp__codex__codex-reply

审稿人接口后，按照

shared-references/review-tracing.md

保存追踪记录。使用

tools/save_trace.sh

或直接将文件写入

.aris/traces/<skill>/<date>_run<NN>/

。遵循

--- trace:

参数（默认：

full

）。