起草、审核或修改Nature风格的修回通信包：逐点回复审稿意见信、反驳信、修回附信、LaTeX附信/回复模板以及标红修改的稿件节选。适用于审稿意见、编辑决定信、粘贴的编辑邮件、回复草稿、附信、回复审稿人、修回信、返修邮件、编辑邮件、返修cover letter、审稿意见回复、逐点回复、大修回复、小修回复、回复审稿人、修改稿回复、写rebuttal、回应审稿意见、标红修改或LaTeX模板。
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/cover-letter/revision-package/latex-template/appeal-like。 - 决定类型 — 小修、大修、修改后重投、审稿后转投或不明确。
- 用户语言 — 如果用户使用中文，还需生成中文核对块。
使用references/intake-and-routing.md在起草前确定任务模式、最小输入和就绪状态。将类似申诉的案例单独路由；不要默认路径起草申诉。
3. 执行工作流
遵循core/workflow.md中的工作流：如果用户粘贴了期刊邮件，首先从邮件中解析稿件元数据、决定类型、编辑指示、审稿报告、所需文件和截止日期；识别模式和决定类型；提取编辑指示（ID E.1），然后提取审稿人意见（R1.1、R2.1）（如有）；按回复操作和独立验证的工作状态对每个项目进行分类；构建策略摘要；起草逐点回复和/或修回附信；将每个声称的修改映射到稿件位置或显式占位符；编辑时在备份副本上用红色标记修改的稿件文本；在回复信中将引用的修改后稿件文本格式化为斜体；在LaTeX/面向打印的输出中，每个新的审稿人回复从新页面开始；标记缺失的作者输入；运行QA；根据每个项目的状态和阻塞状态推导包的就绪状态。
切勿编造实验、引用、行号、图面板、补充项目、编辑指示或稿件修改。将作者必须提供的内容标记为AUTHOR_INPUT_NEEDED。
4. 仅在需要时调用参考
references/和templates/下的文件是深层资源，而非默认值。根据清单中的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/latex-templates.md用于.tex附信/回复/红线输出，以及references/qa-checklist.md用于最终定稿前检查。
为何这样拆分
- 静态层是版本化且可审查的；核心层保持小巧以应对常规回复。
- 动态层使每次调用成本低廉：困难案例、分类和QA深度仅在需要时才加载。
- 路由本身故意简短。当增加范围时，更新片段和参考，而非本文件。
- 此结构镜像了
nature-writing、nature-polishing、nature-reader、nature-paper2ppt、nature-figure和nature-citation。
