Rebuttal Crafter

---
name: rebuttal-crafter
description: 审稿意见回复规范。当用户收到审稿意见/返修邮件，需要写 response letter、逐条回复审稿人、或产出修改对照表时使用。意见逐条编号不遗漏并按类别+严重度分级，大修小修分流定策略；回应分「接受修改/部分接受/礼貌反驳」三型，审稿人漏看按呈现问题处理；产出回复信草稿与修改对照表，承诺与对照表双向核对；不直接改稿件正文，除非用户明确要求。
outputs: [rebuttal/, manuscript/]
provides: [rebuttal-crafter]
---

# 审稿意见回复（rebuttal-crafter）

本技能规定「审稿意见 → 逐条回应 → 回复信 + 修改对照表」的操作规范。目标是让每条意见都有交代、每处修改都可回溯。**回复信是草稿，采纳与否由人定夺；默认不直接改稿件正文。只有调用方的 TASK.md 明确授予“直接生成修订稿”权限时，才可在指定的上一版稿件上改写，并且每处修改必须绑定审稿意见编号；没有该授权时只产出回复信与修改对照表。**

## 何时使用

- 用户粘贴或保存了审稿意见（编辑来信、reviewer comments），要求写返修回复
- 投稿与返修流水线中「审稿意见回复」一步（简报会指向本技能）

## 操作规范

### 1. 意见台账：逐条拆分编号

- 审稿意见全文默认从 `reviews/round-<n>.md` 读取（用户指定其他路径时从其约定）；文件缺失时提示用户提供并停止，**不得编造审稿意见**；
- 逐条拆分并编号：多位审稿人分节（R1.1、R1.2…、R2.1…），编辑意见单列为 E.1…；一条意见含多个诉求时拆成子条；
- **不允许遗漏任何一条**——拆完后回读原文核对数量。
- 每条同时标两个维度：
  - **类别**：表述 / 证据与解释 / 方法 / 统计 / 数据代码材料 / 引用定位 / 范围可行性 / 伦理合规；定不了的标 [待确认]；
  - **严重度**：minor（不动证据链）/ major（影响结论可信度）/ blocking（伦理合规、数据完整性、核心声称无支撑）——blocking 条只给补齐计划，不写自信回复。
- 台账允许标 [关键]：评分低但关切可答的审稿人（pivotal reviewer），其回应写最充分，资源向其倾斜。
- 返修类型分流：决定信写明大修/小修时，分别按「证据优先的工作计划」/「限定范围的精确修订」定策略；未写明时不追问，按大修口径保守处理并在回复信开头标 [待确认：返修类型]；**禁止从意见数量或语气推断返修类型**。

### 2. 逐条定回应类型

每条意见归入三型之一，并在台账中标注：

- **接受修改**：文字/格式/补充说明类，可直接改稿解决；
- **部分接受**：方向认可但需限定范围（如只能补小规模实验、只能引用已有数据），写明限制条件；
- **礼貌反驳**：在有事实证据、方法依据或合理研究边界时使用——必须给出稿件原文位置或文献依据支撑反驳，语气对事不对人。

拿不准如何回应的一律按「部分接受」写，并标 [待确认]；需要补实验/补数据才能回应的标 [待补实验]，在回应中给出可执行的补做计划，不开空头支票。

补充细则：

- **审稿人漏看稿中已有内容 = 呈现问题**：直接回答 + 承认原文呈现不够清楚 + 做小澄清（改措辞/调位置/加指引）+ 给修改位置；禁止「原文已写明」「审稿人误解了」类句式。
- **声称动词校准**：审稿人质疑因果而证据只是相关的，先把动词降档（证明/表明 → 提示/与……一致）再起草回应。
- **超范围实验的标准姿态**：承认价值 → 说明研究设计边界 → 有替代证据给替代证据 → 软化声称或补局限；不得以时间/经费/便利性为首要理由。
- **审稿人点名要求引用的**：只加真正相关且元数据齐全的；元数据不全的标 [待补]，不硬凑。
- **状态校准**：用户声称已改但无可检查产物的标 [待验证]，不写成已改——「草稿存在」不等于「修改完成」。

### 3. 写回复信

产出 `rebuttal/response-letter.md`：

1. 开头一段总述：感谢编辑与审稿人 + 本次修改的要点概括（按实际修改，不凑条数）；
2. 逐条回应，固定结构：**意见摘要**（一两句复述，表明理解）→ **回应**（类型 + 具体处理）→ **修改位置**（稿件的节+段落，或「见修改对照表第 N 条」）；
3. 语气先谢后答；每条回应独立完整，不写「同上」；
4. 反驳条固定五句式：承认关切 → 窄化分歧点 → 给稿件原文位置或文献依据 → 顺手的小澄清 → 收尾对事不对人；
5. 禁止跨审稿人引用：不写「正如审稿人 2 也指出」「见对审稿人 1 的回复」；同一关切被多人提出时各自完整作答；意见冲突时先在台账调和，给各审稿人独立且科学上一致的解释；
6. 回复信中粘贴的修订后正文用斜体，与回应文字区分；
7. 证据优先于断言：反直觉的回应给具体数字；新颖性争议点名最接近的前作 + 精确差异；无强证据时说得少而非多。

**禁用句式**：「审稿人误解了」「原文已写明」「正如原文第 X 节所述」「众所周知」「我们相信这已经足够」「由于经费/时间有限无法」「已相应修改」（不给具体位置时）。

### 4. 修改对照表与修订稿

- 产出 `rebuttal/revisions.md` 修改对照表：意见编号 → 修改点 → 修订稿中的位置（节+段落），逐条可核对；
- **承诺双向核对**：回复信里每处「我们已修改/将修改」必须在对照表有条目，对照表每条必须回溯意见编号；对不上的删掉或标 [待确认]——不在对照表里的承诺 = 空头支票；
- 不触发修改的意见（礼貌反驳/有意不改）也在对照表留一行 + 一句原因，防止「回复了但没改」无法回溯；
- 正文改动最小化：回复信里充分回答，正文只改最短必要文本；优先改写/压缩现有句，不整段追加辩护性文字；
- 用户明确要求改稿时，才在原稿基础上产出 `manuscript/revised.md`，每处修改标注对应的意见编号；未被要求时只产出回复信与对照表，稿件原样保留。

## 完成标准

回复信覆盖台账全部编号（含编辑意见）；每条回应类型明确、有修改位置或 [待补实验] 计划；修改对照表与回复信一一对应；[待确认]/[待补实验] 在回复信末尾汇总成清单。

- blocking 条目若仍只有计划则维持阻塞，不得写已完成或可再投稿；
- 承诺双向核对通过；无跨审稿人引用句式；漏看类意见均按呈现问题口径处理；
- 回复信末尾标就绪度自评：可投稿草稿 / 带占位草稿 / 缺作者输入 / 阻塞。

- 写作约定：不使用彩色 emoji；强调标记用「注意：」或单色 ⚠（U+26A0 U+FE0E）。

---

理念参考：Yuan1z0825/nature-skills（Apache-2.0）nature-response、wanshuiyin/Auto-claude-code-research-in-sleep（MIT）rebuttal、zLanqing/codex-claude-academic-skills（MIT）审稿回复流程；内容为按 Ccode 科研工作流重写。

## 补研究与再投稿门

补实验/数据时先回设计（人批准版本与偏离）→执行（日志/manifest）→分析→独立复算与证据审查；本轮产物单独留存，不覆盖上一轮。复核所有受影响表图、摘要、结论、支持性引用与回复承诺。研究未做不能只生成回复计划就称该轮完成。重大问题只有证据补齐、或人确认撤回/缩窄主张并复核后才关闭；写“不处理理由”不是放行。提交前人确认版本、作者责任、披露与归档清单，保留实际提交回执，不代签/不自动发布。

## 验收入口

有 TASK.md 时沿用其中的验收摘要/质量状态合同，不重复建表；独立使用时，在本报告开头写：回答、关键证据入口、未验证、影响结论的问题、待人决定。状态为待审/有条件接受/证据通过（限定范围）/阻塞；推荐不等于人工批准。