Nature 审稿人回复
起草、审计或修改针对 Nature 家族手稿修改的逐点审稿人回复信。当用户提供审稿人评论、编辑决定信、修改说明、回复草稿，或询问如何回复大修/小修请求、反驳信、回复审稿人、同行评审报告、审稿意见回复、逐点回复、修回信、大修回复、小修回复、如何回复 reviewer 时使用。
文件预览
SKILL.md
| name | nature-response |
|---|---|
| description | 起草、审计或修改针对 Nature 家族手稿修改的逐点审稿人回复信。当用户提供审稿人评论、编辑决定信、修改说明、回复草稿，或询问如何回复大修/小修请求、反驳信、回复审稿人、同行评审报告、审稿意见回复、逐点回复、修回信、大修回复、小修回复、或如何回复 reviewer 时使用。 |
| version | 1.0.0 |
| status | Beta |
| author | Community contribution, refactored into static/dynamic layers |
Nature 审稿人回复 — 路由
此技能分为两层：
static/下的静态层保存受版本控制的、可复用的内容片段（默认立场和红线，以及包含输出格式的回复工作流）。- 动态层（此文件加上
manifest.yaml）每次加载核心内容，仅在步骤需要时才深入加载更详细的回复参考文献。
请勿从记忆或从此路由器直接应用回复逻辑。务必按下面描述的方式从磁盘加载片段。
路由协议
每次调用此技能时，遵循以下四个步骤。
1. 加载清单和核心层
读取 manifest.yaml。然后读取 always_load 下列出的每个文件：
static/core/stance.md— 面向编辑的目的、默认立场、底线和适用于每个回复任务的来源层次。static/core/workflow.md— 接受的输入、十步工作流和输出包格式。
2. 无内容轴 — 内联识别模式和语言
与 nature-writing 或 nature-figure 不同，nature-response 没有片段轴。其变体是在运行时识别的，而不是通过加载不同的内容体：
- 任务模式 —
draft（起草） /audit（审计） /revise（修改） /triage-only（仅分诊） /appeal-like（类申诉）。 - 决定类型 — minor revision（小修）、major revision（大修）、revise-and-resubmit（修改后重投）、transfer after review（审后转投）或 unclear（不明）。
- 用户语言 — 如果用户用中文写作，还需生成
中文核对块。
在起草前，使用 references/intake-and-routing.md 确定任务模式、最低输入和就绪状态。申诉类案件单独路由；不要将申诉作为默认路径起草。
3. 运行工作流
遵循 core/workflow.md 中的十步工作流：识别模式和决定类型，提取编辑指示（ID E.1），然后提取审稿人评论（R1.1，R2.1），对每项分类，构建策略摘要，根据保留的评论逐条起草回复，将每个声称的修改映射到手稿位置或明确的占位符，标记缺失的作者输入，运行 QA，并返回带有就绪状态的回复包。
绝不要编造实验、引文、行号、图面板、补充材料、编辑指示或手稿修改。将作者必须提供的任何内容标记为 AUTHOR_INPUT_NEEDED。
4. 仅在需要时加载参考文献
references/ 下的文件是深层参考，而非默认加载。根据清单中的 references.on_demand 表按需打开它们——例如，使用 references/comment-taxonomy.md 分类评论，使用 references/action-mapping.md 获取跟踪字段，使用 references/tone-and-stance.md 处理分歧措辞，使用 references/difficult-cases.md 处理不可能的实验/冲突的审稿人/申诉类案例，使用 references/chinese-author-alignment.md 处理中文作者注释，并在定稿前使用 references/qa-checklist.md。
为何这样分割
- 静态层是受版本控制且可审查的；核心内容保持简洁，适用于常规回复。
- 动态层使每次调用开销小：困难案例、分类和 QA 深度仅在需要时加载。
- 路由器本身故意简短。在添加范围时更新片段和参考文献，而不是此文件。
- 此结构模仿了
nature-writing、nature-polishing、nature-reader、nature-paper2ppt、nature-figure和nature-citation。