nature-response

interface:
  display_name: "Nature Response"
  short_description: "Draft isolated reviewer responses and revision packages"
  default_prompt: "Use $nature-response to prepare mutually isolated reviewer responses and a consistent revision package."

# Example: conflicting reviewers

This synthetic example shows how editor instructions and evidence limits control the response when
reviewers request incompatible claim strength.

## Input

```text
Editor:
Please avoid expanding the manuscript substantially and focus on clarifying the central claim.

Reviewer 1:
1. The abstract should make a stronger causal claim that X drives Y.

Reviewer 2:
1. The causal language is not supported by the observational design and should be softened.

Author notes:
- The study is observational.
- We can soften the abstract and discussion.
- We can state that the findings support an association, not causality.
```

## Expected handling

- Assign the editor instruction `E.1`.
- Assign reviewer comments `R1.1` and `R2.1`.
- Surface the conflict only in the internal/editor strategy summary.
- Prioritize the editor instruction and the observational design.
- Use `SOFTEN_CLAIM` for `R2.1`.
- Use `PARTIAL` or `DISAGREE` for `R1.1`, with respectful reasoning.

## Reviewer 1 response style

```text
We appreciate the reviewer's suggestion to sharpen the abstract. However, because the study is
observational, stronger causal wording would go beyond the evidence available in the present
study. We have therefore revised the abstract and Discussion to state that the findings support
an association between X and Y rather than a causal relationship.
```

## Reviewer 2 response style

```text
We agree that the observational design does not support a causal interpretation. We have revised
the abstract and Discussion to state that the findings support an association between X and Y
rather than a causal relationship.
```

The response must not promise both stronger causal language and softened causal language. The
Reviewer 1 file must not mention Reviewer 2 or the conflicting request, and the Reviewer 2 file
must not mention Reviewer 1.

# Example: major revision with missing evidence

This synthetic example shows how to avoid fabricated compliance when an author note is incomplete.

## Input

```text
Editor decision: Major revision.

Reviewer 1:
1. The manuscript requires validation in an independent cohort.
2. The replicate definition in the statistical analysis is unclear.

Author notes:
- We added validation using dataset GSEXXXX in Fig. 5.
- We fixed the statistics description.
```

## Expected handling

```text
Response strategy summary
- Decision type: Major revision
- Task mode: draft
- Package readiness: needs_author_input
- Major risks: validation results and statistical details are missing
```

The response may mention `GSEXXXX` and `Fig. 5` because they were supplied. It must not invent:

- validation performance;
- sample size;
- p-values;
- confidence intervals;
- statistical test names;
- Methods or Results line numbers.

## Required author questions

```text
Missing information / risk flags
- R1.1: Please provide the validation result summary, cohort size or dataset scale, and Results/Fig. 5 location.
- R1.2: Please provide the statistical test name, replicate unit, sample size, correction method, and Methods location.
```

## Response style

```text
To address this concern, we added an independent validation analysis using dataset GSEXXXX,
which is presented in Fig. 5. The final response requires the validation result summary and
manuscript location before it can be marked ready_to_submit.
```

# Example: minor revision response package

This synthetic example shows the expected output shape for a minor revision. It is not based on
real reviewer comments.

## Input

```text
Editor decision: Minor revision.

Reviewer 1:
1. Please define cross-domain calibration in the Introduction.
2. Figure 2 legend does not explain the colour scale.

Author notes:
- Cross-domain calibration means adjusting the model output across datasets with different feature distributions.
- We added a definition in the Introduction.
- We revised the Figure 2 legend to define the colour scale.
- No line numbers are available.
```

## Expected response strategy summary

```text
Response strategy summary
- Decision type: Minor revision
- Task mode: draft
- Package readiness: draft_with_placeholders
- Overall posture: Cooperative and concise
- Major risks: line numbers are not available
- Suggested ordering: Reviewer 1 comments in order
```

## Expected tracker

```markdown
| ID | Reviewer concern | Type | Severity | Proposed action | Work status | Required input | Expected output | Blocks finalization? |
|---|---|---|---|---|---|---|---|---|
| R1.1 | Define cross-domain calibration | Editorial / presentation | Minor | ACCEPT_TEXT | REPORTED_DONE_UNVERIFIED | Revised passage and location | Verified Introduction definition | Yes |
| R1.2 | Explain Figure 2 colour scale | Editorial / figure | Minor | ACCEPT_FIGURE | REPORTED_DONE_UNVERIFIED | Revised legend and location | Verified Figure 2 legend | Yes |
```

## Response style

```text
We agree that the original Introduction did not define this term clearly. We have revised the
Introduction to define cross-domain calibration as adjustment of model output across datasets with
different feature distributions. This change appears in the Introduction [location].
```

Do not invent line numbers.

name: nature-response
version: 1.7.0
description: >
  Declarative manifest for the static/dynamic split. SKILL.md uses this to
  decide which fragments and templates to load for a reviewer-response or
  revision-cover-letter request.

# Design note: nature-response is a linear, parameterised workflow (intake ->
# extract editor/reviewer items -> classify -> strategise -> draft -> map ->
# QA -> package). Its variation — task mode (draft/audit/revise/triage/cover-letter/
# revision-package/latex-template/appeal),
# decision type, user language — is identified at runtime, mainly by
# references/intake-and-routing.md, not by loading different large content
# bodies. There is therefore no content axis; the split is core (always loaded)
# plus the existing on-demand references. nature-response keeps its own
# response-specific stance and source basis, but loads the shared main-text
# discipline when a reviewer response proposes or performs manuscript edits.

always_load:
  - static/core/stance.md
  - static/core/workflow.md

references:
  on_demand:
    - condition: a reviewer or editor comment leads to additions, deletions, compression, relocation, or statistical-detail changes in the manuscript main text — classify the result, prevent revision accretion, separate main text/caption/SI functions, and run deletion, paragraph-necessity, and claim-repetition checks
      path: ../nature-shared/core/main-text-discipline.md
    - condition: before drafting — identify task mode, enforce the Major/Minor decision-type gate, parse pasted decision emails, minimum inputs, editor IDs, readiness state, and clarifying-question need
      path: references/intake-and-routing.md
    - condition: source hierarchy, rule provenance, or policy-vs-advice boundaries
      path: references/source-basis.md
    - condition: the response package format, mutually blind reviewer separation, point-by-point letter anatomy, cover-letter anatomy, marked-manuscript rules, or LaTeX deliverable routing
      path: references/response-structure.md
    - condition: the user requests a LaTeX cover-letter template, LaTeX response-to-reviewers template, red-marked manuscript template, or filled .tex revision package
      path: references/latex-templates.md
    - condition: classify reviewer comments by category and severity
      path: references/comment-taxonomy.md
    - condition: action labels, per-item work status, tracker fields, blocking state, and missing-input states
      path: references/action-mapping.md
    - condition: recommended language, forbidden phrasing, disagreement tone, or a reviewer missed material already present in the manuscript
      path: references/tone-and-stance.md
    - condition: the user writes in Chinese or provides Chinese author notes
      path: references/chinese-author-alignment.md
    - condition: impossible experiments, factual errors, conflicting or repeated reviewer requests, reviewer-visibility isolation, citations, statistics, compliance, transfer, or appeal-like cases
      path: references/difficult-cases.md
    - condition: before finalizing an output or auditing a draft response
      path: references/qa-checklist.md
    - condition: the manuscript is being edited alongside the letter, the package has been through more than one editing round, or the package is about to be compiled and delivered — verbatim quote synchronization, red-marking baseline, deletion ripple, volatile page references, manuscript numeric self-consistency, terminology sweeps, and the clean/marked delivery gate
      path: references/package-consistency-audit.md

quality_tools:
  package_consistency_script: scripts/check_package_consistency.py
  use_when: after the first complete LaTeX revision package, after every manuscript edit, and immediately before delivery
  purpose: expand static LaTeX inputs, check response-letter quotes and declared rendered substitutions against the manuscript, pair reviewer comments with author responses, and compare clean and marked manuscript text after additions and deletions are normalized
  script_resolution: resolve relative to the loaded SKILL.md directory, never the user working directory

# `nature-response` Skill

[中文说明](README.md)

`nature-response` drafts, audits, and revises revision correspondence, including mutually isolated point-by-point reviewer responses, revision cover letters, red-marked manuscript excerpts, and editable LaTeX templates.

## What To Use It For

- Parse editor decision letters, revision emails, and reviewer reports.
- Confirm whether the decision is Major Revision or Minor Revision before applying the corresponding revision strategy.
- Split comments into stable IDs such as `E.1`, `R1.1`, and `R2.3`.
- Treat different reviewers as mutually blind by default. Keep a master tracker internally while giving each reviewer a standalone response that reveals no other reviewer's comments, IDs, recommendation, or response text.
- Answer repeated concerns fully for each reviewer. Reconcile conflicting requests only in the internal/editor master without telling one reviewer what another requested.
- Build response strategy, manuscript-change actions, and evidence needs for each comment.
- Track response action, task progress, and package readiness separately, with inspectable evidence for completed work.
- Draft formal, restrained, submission-ready English point-by-point responses and cover letters.
- Audit rebuttal drafts for missed replies, defensive tone, unsupported claims, and missing line numbers.
- When a reviewer misses material already present in the manuscript, treat it as a clarity problem and improve the presentation instead of replying that it was already stated.
- Answer the reviewer fully in the letter but keep manuscript changes to what readers need for the central inference; every new main-text sentence triggers a replacement, compression, deletion, or SI-relocation check to prevent revision accretion.
- Mechanically check LaTeX revision packages for quoted-text drift, comment-response count mismatches, and clean-versus-marked manuscript text drift.

## Typical Requests

- "Here is the editor email and reviewer comments; generate a point-by-point response framework."
- "Turn my Chinese revision notes into English reviewer responses."
- "Check whether this rebuttal misses anything, sounds too strong, or lacks evidence."

## What You Need To Provide

- Editor decision letter, reviewer comments, revision requirements, or existing rebuttal draft.
- If the decision letter does not state it, whether this is a Major Revision or Minor Revision.
- Completed or planned experiments, analyses, figures, line numbers, and manuscript-change locations.
- Target journal, manuscript ID, title, and required submission files.

## Outputs

- Response strategy summary.
- Separate point-by-point response letters for each reviewer, a revision cover letter, or a LaTeX response package.
- An author/editor master tracker clearly labelled as not reviewer-facing.
- Manuscript-change checklist, missing-information checklist, and risk notes.
- Per-item tracker with work status, required input, expected output, and finalization-blocking state.
- Optional red-marked manuscript excerpts; manuscript text must come from the author.
- A mechanical package-consistency report; compiled page locations, colors, citations, and references still require final PDF verification.

## Boundaries

- The skill does not invent experiments, analyses, line numbers, figures, statistical results, or editor requirements.
- It does not use cross-reviewer phrases such as "another reviewer also noted" or "see our response to Reviewer 2" in a reviewer-facing response.
- It does not rebuke reviewers with "we already stated this". It answers directly, clarifies the presentation, and identifies the revised location.
- It does not turn the main text into a pre-emptive reviewer response or keep appending non-central robustness and recursive reconciliation prose to Results.
- Information that needs author confirmation is marked in Chinese rather than written as fact.
- For pre-submission simulated review, use `nature-reviewer`.

## Related Skills

- `nature-reviewer`: simulate reviewer comments before submission.
- `nature-polishing`: polish reviewer-response and cover-letter English.
- `nature-statistics`: handle statistical reviewer comments.
- `nature-ref-verifier`: verify reference-error comments.

# `nature-response` 技能

[English](README_EN.md)

`nature-response` 用于起草、审查和修改返修通信材料，包括互相隔离的逐点 reviewer response、revision cover letter、标红修改稿摘录和可编辑 LaTeX 模板。

## 适合用它做什么

- 解析编辑部决定信、返修邮件和 reviewer reports。
- 先确认是 Major Revision（大修）还是 Minor Revision（小修），再采用对应的返修策略。
- 将意见拆成稳定编号，例如 `E.1`、`R1.1`、`R2.3`。
- 默认将不同审稿人视为互盲。内部保留总表，给每位审稿人的回复独立成文，不泄露其他审稿人的意见、编号、建议或回复内容。
- 多位审稿人提出相同问题时分别完整回答。意见冲突只在内部或给编辑的总表中协调，不向某位审稿人提及另一位审稿人的要求。
- 为每条意见制定回应策略、手稿修改动作和证据需求。
- 分开记录“采用什么回应动作”“任务做到哪一步”“整个回复包能否提交”，并要求完成状态有可核验材料。
- 起草正式、克制、可提交的英文逐点回复和 cover letter。
- 审查 rebuttal 草稿中的遗漏回复、防御性语气、无支撑声称和行号缺口。
- 审稿人没有看到原文已有内容时，将其视为表达不够清楚，主动补充说明或调整位置，而不是回复“文中已经写过”。
- 回复信完整回应审稿人，但手稿修改只保留读者理解中央结论所必需的内容；每次新增主文句子都检查能否替换、压缩或移至 SI，防止返修累积。
- 对 LaTeX 返修包自动核对回复信引用、意见与回复数量，以及清稿和标红稿的正文一致性。

## 典型请求

- “这是编辑邮件和审稿意见，帮我生成逐点回复框架。”
- “把我的中文修改说明改成英文 reviewer response。”
- “检查这份 rebuttal 是否漏回、语气是否太强、有没有缺证据。”

## 你需要提供

- 编辑决定信、审稿意见、返修要求或已有 rebuttal 草稿。
- 若决定信未明确说明，请告知这是 Major Revision（大修）还是 Minor Revision（小修）。
- 已完成或计划完成的实验、分析、图表、行号和手稿修改位置。
- 目标期刊、稿件号、题名和提交材料要求。

## 产出

- Response strategy summary。
- 给每位审稿人分别生成的逐点回复信、返修 cover letter 或 LaTeX response package。
- 供作者或编辑核对的总表，明确标记为不面向审稿人。
- 手稿修改清单、缺失信息清单和风险提示。
- 带任务状态、所需输入、预期产物和是否阻塞最终提交的逐条 tracker。
- 可选标红修改稿摘录；原文修改必须基于作者提供的文本。
- 返修包机械一致性报告；编译页码、颜色、引用和参考文献仍需在最终 PDF 中核验。

## 边界

- 不会编造实验、分析、行号、图版、统计结果或编辑要求。
- 不会在某位审稿人的回复中写“另一位审稿人也提出了”或“见我们对 Reviewer 2 的回复”等交叉信息。
- 不会用“我们已经在文章中说明”责备审稿人，而会直接回答、进一步澄清并标明修改后的具体位置。
- 不会把主文写成预防性 reviewer response，也不会把非核心稳健性和解释性递归不断追加到 Results。
- 对需要作者确认的信息会用中文标记，而不是直接写成事实。
- 如果任务是模拟投稿前审稿意见，优先使用 `nature-reviewer`。

## 相关技能

- `nature-reviewer`：投稿前模拟审稿人意见。
- `nature-polishing`：回复信和 cover letter 的英文语气打磨。
- `nature-statistics`：处理统计相关审稿意见。
- `nature-ref-verifier`：核查参考文献错误类意见。

# Action mapping

## Contents

- [Action labels](#action-labels)
- [Internal tracker fields](#internal-tracker-fields)
- [Work status](#work-status)
- [Task-control fields](#task-control-fields)
- [Readiness state](#readiness-state)
- [Risk level](#risk-level)
- [Mapping rules](#mapping-rules)


Use this file to map every reviewer concern to a concrete response action.

## Action labels

| Action label | Meaning | Use when |
|---|---|---|
| `ACCEPT_TEXT` | Revised wording, structure, title, abstract, Methods detail, Discussion, or legend | The author supplied or can supply a text change |
| `ACCEPT_ANALYSIS` | Added or revised analysis | The response depends on real analysis output |
| `ACCEPT_EXPERIMENT` | Added experimental data | The author performed a real experiment and supplied enough detail |
| `ACCEPT_FIGURE` | Added or modified figure, table, panel, legend, or supplement | A visual or tabular item addresses the concern |
| `CLARIFY_EXISTING` | Existing data already address the concern, but manuscript presentation needed clarification | The evidence exists and location can be cited |
| `ADD_CITATION` | Added verified citation | The citation is genuinely relevant and metadata is supplied or flagged |
| `SOFTEN_CLAIM` | Reduced claim strength or added boundary | The original claim was too broad, causal, novel, clinical, or mechanistic |
| `PARTIAL` | Partly addressed with explicit remaining limitation | A valid concern cannot be fully resolved in the revision |
| `DISAGREE` | Respectfully disagree with evidence or scope-based reasoning | The reviewer interpretation is not supported by the manuscript facts |
| `OUT_OF_SCOPE` | Valid suggestion but outside current manuscript scope | The request requires a new cohort, system, longitudinal design, or different study |
| `AUTHOR_INPUT_NEEDED` | Cannot draft final answer without real details | The author note is vague, missing, or unsupported |
| `BLOCKING` | Revision cannot be credible until author action occurs | Missing ethics, compliance, central evidence, integrity explanation, or required data |

## Internal tracker fields

Use this shape internally when organizing a response:

```yaml
comment_id: R1.3
reviewer: Reviewer 1
severity: major
category: methodological
action: ACCEPT_ANALYSIS
work_status: TODO_ANALYSIS
required_input: Analysis specification and result output
expected_output: Updated Results text and Supplementary Table S2
verification_evidence: null
blocks_finalization: true
package_readiness: needs_author_input
risk_level: high
manuscript_location: Methods; Results; Supplementary Fig. S2
```

Keep these dimensions separate:

- `action`: the scientific or editorial response approach;
- `work_status`: how far the concrete task has progressed and whether completion is verified;
- `package_readiness`: whether the complete response package can be submitted safely.

The IDs in this tracker belong to the internal/editor master. In each reviewer-facing response,
map only that reviewer's IDs to neutral local labels such as `Comment 1`. Never expose another
reviewer's IDs in the outward-facing file.

## Work status

| Status | Meaning | Minimum evidence |
|---|---|---|
| `VERIFIED_DONE` | The requested change or justified response is complete and independently traceable | Supplied revised text, analysis output, figure/table, repository record, approval, or other inspectable artifact |
| `REPORTED_DONE_UNVERIFIED` | The author reports completion, but the revised artifact was not supplied or cannot be matched | Explicit author statement only |
| `TODO_TEXT` | Manuscript or response wording still needs to be written or revised | Clear target section and requested change |
| `TODO_ANALYSIS` | A computational, statistical, or data-analysis task remains | Analysis specification and required inputs |
| `TODO_EXPERIMENT` | Experimental, clinical, field, or validation work remains | Study task and required design details |
| `TODO_AUTHOR_CONFIRM` | The proposed action requires an author decision or missing factual confirmation | A concrete author question |
| `NOT_FEASIBLE` | The requested work cannot reasonably be completed within the study design or revision | Scientific, ethical, scope, or data-based rationale plus an alternative response |
| `PROPOSED_DISAGREEMENT` | A disagreement is recommended but not yet approved and evidenced | Draft reasoning, supporting evidence, and author confirmation request |

Status rules:

- A drafted reply is not proof that the manuscript was changed.
- Use `VERIFIED_DONE` only after matching the claimed action to an inspectable artifact and record it in `verification_evidence`.
- Use `REPORTED_DONE_UNVERIFIED` when the author explicitly says the work was completed but does not supply the revised artifact.
- `NOT_FEASIBLE` is not automatically submission-ready; the response still needs a defensible rationale, an appropriate limitation or claim adjustment, and author approval.
- After the author approves an evidence-backed disagreement, record the response action as `DISAGREE`; use `VERIFIED_DONE` only when the final response and any manuscript clarification are inspectable.

## Task-control fields

- `required_input`: the next concrete fact, file, decision, or result needed; use `None` only when genuinely complete.
- `expected_output`: the artifact that will demonstrate completion, such as revised Methods text, a robustness-analysis table, a new figure panel, or a finalized disagreement paragraph.
- `verification_evidence`: the supplied location or artifact used to justify `VERIFIED_DONE`.
- `blocks_finalization`: `true` when the unresolved item prevents a credible final response or submission-ready package.

## Readiness state

| State | Meaning |
|---|---|
| `ready_to_submit` | No item blocks finalization, every claimed completed change is verified, and no unresolved placeholder remains |
| `draft_with_placeholders` | Draft can proceed, but placeholders must remain visible |
| `needs_author_input` | Do not draft final wording until author supplies facts |
| `blocked` | Revision response would be misleading or non-credible without author action |

Derive package readiness conservatively:

- Use `ready_to_submit` only when no item blocks finalization, no unresolved placeholder remains, and every claimed completed change is `VERIFIED_DONE`.
- Use `draft_with_placeholders` when usable prose exists but one or more non-final artifacts or locations remain unresolved.
- Use `needs_author_input` when at least one item is `TODO_AUTHOR_CONFIRM`, `REPORTED_DONE_UNVERIFIED`, or otherwise depends on missing facts.
- Use `blocked` when a central-evidence, integrity, ethics, compliance, or essential revision task prevents credible finalization.

## Risk level

| Risk | Use when |
|---|---|
| `low` | Wording, format, or straightforward clarification |
| `medium` | Citation, figure, method detail, or presentation issue requiring verification |
| `high` | Evidence, statistics, validation, claim strength, or out-of-scope request |
| `blocking` | Ethics, compliance, data integrity, missing central evidence, or unsupported response |

## Mapping rules

- If the author says only "we revised it", use `AUTHOR_INPUT_NEEDED` until the location and nature of the revision are known.
- If the author explicitly reports a completed change without providing the revised artifact, use `REPORTED_DONE_UNVERIFIED`, never `VERIFIED_DONE`.
- If the author says "we added an experiment", request experiment name, condition, sample size or replicate unit, result summary, and figure/table location.
- If the author says "we added a citation", request verified bibliographic detail unless already supplied.
- If a reviewer asks for impossible or out-of-scope work, use `PARTIAL` or `OUT_OF_SCOPE` plus claim softening or limitation.
- If a reviewer missed information already present in the manuscript, use `CLARIFY_EXISTING` with a small presentation improvement. Do not reply that the information was already stated or imply that the reviewer failed to read carefully.
- If a central claim remains unsupported, use `SOFTEN_CLAIM` or `BLOCKING`, not confident compliance language.

# Chinese author alignment

Use this file when the user writes in Chinese, provides Chinese author notes, or asks for
`中文核对`, `中英对照`, `审稿意见回复`, `逐点回复`, `修回信`, `大修回复`, or `小修回复`.

## Default behavior

- Accept Chinese reviewer summaries, author notes, manuscript-change notes, and mixed Chinese-English inputs.
- Draft the final point-by-point response letter in English unless the user explicitly asks for Chinese only.
- Keep a short `中文核对` section for unresolved author actions when it helps the author act.
- Translate intent, not literal wording.
- Convert vague Chinese notes into concrete response evidence requirements.

## Common Chinese note conversions

| Chinese note | Problem | Better handling |
|---|---|---|
| `我们已经改了` | Too vague | Ask what changed, where it appears, and whether revised text is available |
| `按审稿人意见修改` | No action mapping | Convert to `AUTHOR_INPUT_NEEDED` until action and location are known |
| `我们补了实验` | Missing evidence | Request experiment name, conditions, replicate/sample details, result summary, and figure/table location |
| `我们补了分析` | Missing analysis detail | Request analysis method, data source, key result, statistical output, and manuscript location |
| `这个问题不重要` | Defensive and unsupported | Reframe as scope, evidence, or claim-boundary reasoning if scientifically justified |
| `由于时间原因没做` | High-risk excuse | Replace with study-design or scope boundary only if true; otherwise flag risk |
| `审稿人误解了` | Accusatory | Reframe as manuscript clarity issue and add clarification |
| `详见正文` | Not traceable | Require section, page, line, figure, table, or supplement |
| `我们认为足够了` | Unsupported sufficiency claim | Explain what evidence addresses the concern or mark remaining limitation |

## Chinese confirmation section

Use concise Chinese action notes:

```text
中文核对
- R1.1: 请补充验证分析的主要结果、样本量或数据集规模，以及 Fig. 5 对应的正文位置。
- R1.2: 请确认统计检验名称、重复单位、样本量和多重检验校正方法。
- R2.1: 目前不能声称已完成动物验证；建议改为范围说明 + Discussion limitation。
```

## Bilingual drafting pattern

When the user supplies Chinese notes:

1. Preserve reviewer comments in their supplied language unless asked to translate.
2. Build the tracker using English action labels.
3. Draft the response letter in polished English.
4. Add `中文核对` only for decisions, missing facts, and high-risk issues.

## Tone correction examples

Chinese author note:

```text
审稿人没有理解我们的方法。
```

Response stance:

```text
We agree that the original Methods description did not make this distinction sufficiently clear.
We have revised the Methods to clarify [specific distinction and location].
```

Chinese author note:

```text
这个实验超出了我们的能力。
```

Response stance:

```text
We agree that this experiment would provide an additional test of [claim]. However, it would require
[new cohort/system/longitudinal design], which is outside the scope of the present study. We have
therefore softened the claim and added a limitation in [location].
```

# Comment taxonomy

Use this file to classify reviewer comments before drafting responses.

## Severity

| Severity | Meaning | Default handling |
|---|---|---|
| `minor` | Presentation, clarity, formatting, citation, or small method-detail issue that does not alter the main evidence chain | Usually draftable with text change or citation placeholder |
| `major` | Evidence, validation, method, statistics, interpretation, or scope issue that may affect claims or editorial confidence | Requires explicit action, evidence, or author input |
| `blocking` | Ethics, compliance, data integrity, missing required approval, unsupported central claim, or unresolved fatal methodological issue | Do not draft a confident response without author action |
| `unclear` | Insufficient information to judge severity | Flag for author confirmation |

## Categories

### Editorial / presentation

Includes unclear writing, structure problems, missing definitions, figure readability, title/abstract mismatch, or confusing terminology.

Default strategy:

- Usually `ACCEPT_TEXT` or `ACCEPT_FIGURE`.
- Revise wording, structure, legend, definition, or abstract-title alignment.
- Give section, page, line, figure, or placeholder.

### Evidence / interpretation

Includes unsupported claims, overinterpretation, missing control, causal claim not justified, clinical relevance not shown, or alternative explanation.

Default strategy:

- Use `ACCEPT_EXPERIMENT`, `ACCEPT_ANALYSIS`, `SOFTEN_CLAIM`, `CLARIFY_EXISTING`, `PARTIAL`, or `DISAGREE`.
- Do not invent results.
- If evidence is absent, soften the claim and add a limitation.

### Methodological

Includes missing method detail, reproducibility issue, missing baseline, missing validation, unclear sample size, software/model/version not stated.

Default strategy:

- Use `ACCEPT_TEXT`, `ACCEPT_ANALYSIS`, or `AUTHOR_INPUT_NEEDED`.
- Request exact method details when author notes are vague.
- Map to Methods, Supplementary Methods, protocol, code, or figure/table.

### Statistical

Includes inappropriate test, missing effect size, multiple testing issue, insufficient power, missing confidence interval, unclear replicate definition.

Default strategy:

- Treat major statistical critiques as high risk until details are supplied.
- Ask for test name, replicate unit, sample size, correction method, effect size, confidence interval, and exact results where relevant.
- Do not invent p-values, confidence intervals, sample sizes, or effect sizes.

### Data / code / materials

Includes missing accession number, source data unavailable, code not provided, restricted data not justified, FAIR metadata incomplete, materials availability.

Default strategy:

- Use `ACCEPT_TEXT`, `CLARIFY_EXISTING`, `AUTHOR_INPUT_NEEDED`, or `BLOCKING`.
- Request repository, accession, DOI, license, access route, or restriction reason.
- Coordinate with `nature-data` if the user asks for full data-availability wording.

### Citation / positioning

Includes missing prior work, inaccurate novelty claim, wrong comparison, field context incomplete, reviewer-requested citation.

Default strategy:

- Use `ADD_CITATION`, `SOFTEN_CLAIM`, `CLARIFY_EXISTING`, or `DISAGREE`.
- Add citations only when genuinely relevant and verified.
- Do not fabricate DOI, publication year, title, journal, or authors.

### Scope / feasibility

Includes requested experiments beyond scope, future-work suggestions, journal-fit concerns, transfer-related concerns.

Default strategy:

- Use `PARTIAL`, `OUT_OF_SCOPE`, `SOFTEN_CLAIM`, or `DISAGREE`.
- Acknowledge scientific value.
- Give a study-design or scope reason, offer alternative evidence, and add a limitation.
- Avoid time, funding, or convenience as the primary reason.

### Ethics / compliance

Includes ethics approval missing, consent missing, animal/human-subject reporting, competing interests, image/data integrity, or permissions.

Default strategy:

- Usually `BLOCKING` or `AUTHOR_INPUT_NEEDED`.
- Request exact approval number, institution, consent statement, reporting checklist, image-processing details, or data-integrity explanation.
- Do not draft around missing required compliance.

# Difficult cases

## Contents

- [Impossible or out-of-scope experiment](#impossible-or-out-of-scope-experiment)
- [Reviewer factual error](#reviewer-factual-error)
- [Conflicting reviewer requests](#conflicting-reviewer-requests)
- [Repeated concerns across reviewers](#repeated-concerns-across-reviewers)
- [Reviewer-requested citation](#reviewer-requested-citation)
- [Major statistical critique](#major-statistical-critique)
- [Ethics, compliance, or data-integrity critique](#ethics-compliance-or-data-integrity-critique)
- [Transfer after review](#transfer-after-review)
- [Appeal-like case](#appeal-like-case)


Use this file when comments cannot be handled with straightforward acceptance and revision.

## Impossible or out-of-scope experiment

Use when the requested work requires a new cohort, long follow-up, new animal model, new clinical
trial, new platform, or different study design.

Strategy:

1. Acknowledge scientific value.
2. Explain the study-design or scope boundary.
3. Offer alternative evidence if supplied.
4. Soften the claim or add a limitation.
5. Avoid time, budget, convenience, or ability excuses.

Template:

```text
We agree that [experiment] would provide an additional test of [claim]. However, the central
conclusion of the present study is based on [existing evidence], and the requested experiment
would require [new system/cohort/longitudinal design] beyond the scope of this revision.
To avoid overstatement, we have revised [location] to acknowledge this limitation and now state
that [revised text or placeholder].
```

## Reviewer factual error

Use when the reviewer appears to have missed existing data or made a factually incorrect statement.

Strategy:

1. Do not accuse the reviewer.
2. Do not say that the answer was already stated or that the reviewer should have found it.
3. Treat the missed point as evidence that the original presentation was not sufficiently clear or visible.
4. Answer the scientific concern directly.
5. Make or propose a small wording, placement, signposting, legend, or cross-reference improvement.
6. Cite the revised manuscript location or use a visible placeholder when the author has not supplied it.

Template:

```text
We appreciate the reviewer raising this point. We agree that the original presentation did not
make [specific point] sufficiently clear. We have therefore revised [location] to state that
[revised text or faithful summary].
```

## Conflicting reviewer requests

Use when two reviewers ask for incompatible changes.

Strategy:

1. Surface the conflict internally in the strategy summary.
2. Prioritize explicit editor instructions if supplied.
3. Find the minimal revision that satisfies both concerns.
4. Avoid making incompatible promises.
5. Draft each reviewer-facing response independently using only that reviewer's concern and the manuscript evidence.
6. Do not tell either reviewer what another reviewer requested, recommended, or received in response.

The internal/editor master may explain the conflict. A reviewer-facing response must not. For
example, do not write "Reviewer 2 requested the opposite" or "as noted in our response to Reviewer
1". Explain the same scientifically coherent manuscript decision separately to each reviewer.

## Repeated concerns across reviewers

Use when two or more reviewers independently raise the same issue.

Strategy:

1. Link the duplicate concerns only in the internal/editor master.
2. Keep one scientifically consistent manuscript action.
3. Give each reviewer a complete standalone explanation of that action.
4. Do not save space by referring one reviewer to another reviewer's response.

## Reviewer-requested citation

Use when a reviewer asks for a specific citation or broader literature coverage.

Strategy:

1. Evaluate relevance.
2. Add only genuinely relevant and verified citations.
3. Do not imply coercion or reviewer self-citation.
4. Use neutral positioning language.
5. If citation metadata is missing, use `AUTHOR_INPUT_NEEDED`.

## Major statistical critique

Treat as high risk or blocking until details are supplied.

Request:

- statistical test name
- replicate unit
- sample size or replicate count
- effect size or estimate when relevant
- confidence interval when relevant
- p-value only when supplied and appropriate
- multiple-testing correction
- software and version if relevant
- Methods and Results locations

Do not invent statistical output.

## Ethics, compliance, or data-integrity critique

Usually `BLOCKING` until author provides exact facts.

Request:

- ethics approval body and approval number
- consent statement
- animal or human-subject reporting details
- competing-interest correction
- image-processing or data-integrity explanation
- data, code, materials, or accession information

Do not write around missing required compliance.

## Transfer after review

Use when a manuscript is transferred with reviewer reports.

Strategy:

1. Identify whether the receiving journal expects a response to transferred reports.
2. Preserve reviewer IDs from the transferred review package when possible.
3. Address comments as normal revision concerns unless the new editor gives different instructions.
4. Flag journal-specific formatting or scope differences.

## Appeal-like case

Appeals are not ordinary revision responses.

Route separately when:

- the user wants to challenge rejection rather than revise;
- the decision letter invites an appeal path;
- the author alleges major factual error, bias, or process failure;
- no revised manuscript is being prepared.

Default action:

```text
This appears to be an appeal-like case rather than a revision response. `nature-response`
can identify the disputed points, but a full appeal letter should be handled as a separate task
with journal-specific appeal rules.
```

# Intake and routing

## Contents

- [Mandatory decision-type gate](#mandatory-decision-type-gate)
- [Task modes](#task-modes)
- [Readiness states](#readiness-states)
- [Editor instruction handling](#editor-instruction-handling)
- [Pasted editorial email handling](#pasted-editorial-email-handling)
- [Minimum information by output type](#minimum-information-by-output-type)
- [Clarifying question rules](#clarifying-question-rules)
- [Routing shortcuts](#routing-shortcuts)


Use this file before splitting comments or drafting prose. Its job is to decide what task the
user is asking for, whether the supplied information is enough, and what output state is honest.

## Mandatory decision-type gate

For `draft`, `audit`, `revise`, `triage-only`, `cover-letter`, and `revision-package` modes, identify
the editorial decision before drafting strategy or prose.

- If an editor letter explicitly says `Major Revision` or `Minor Revision`, use that value and do
  not ask a redundant question.
- If the user explicitly says 大修、小修, major review, minor review, major revision, or minor
  revision, normalize it to the corresponding revision type.
- If neither source resolves it, ask in the user's language and pause. Chinese default:
  `这是 Major Revision（大修）还是 Minor Revision（小修）？如果决定信没有明确写，请把决定信发给我，我帮你判断。`
  English default: `Is this a Major Revision or a Minor Revision? If the decision letter does
  not state it clearly, please send it and I can help classify the decision.`
- Never guess from the number or apparent difficulty of reviewer comments. Reviewer requests and
  editor instructions can be serious even when the package is labelled Minor Revision.
- `revise-and-resubmit` and `transfer after review` remain distinct decision types; do not force
  either into Major or Minor Revision. Follow the explicit editor instructions for those routes.

Once resolved, apply the Major/Minor strategy in `static/core/workflow.md` and record the chosen
decision type in the response strategy summary.

## Task modes

| Mode | Use when | Minimum useful input | Default output |
|---|---|---|---|
| `draft` | User wants a new point-by-point response package | Reviewer comments plus any author actions or manuscript-change notes | Internal/editor master plus separate reviewer-specific responses with placeholders where needed |
| `audit` | User provides an existing response draft and asks whether it is good enough | Response draft; reviewer comments when available | Findings first, then revised or annotated response sections |
| `revise` | User wants a draft rewritten for tone, traceability, or Nature-style response | Existing draft plus target change request | Revised response text plus changed-risk notes |
| `triage-only` | User wants strategy, action list, or missing inputs before writing prose | Reviewer comments or editor letter | Tracker, action map, missing-input list, no final letter |
| `cover-letter` | User asks for a revision cover letter only | Manuscript metadata plus revision summary or change notes | Concise editor-facing cover letter |
| `revision-package` | User asks for a complete revision package or pastes a decision email and wants the agent to begin | Decision email or reviewer/editor comments plus available author actions | Internal/editor master, reviewer-separated response files, cover letter when useful, change checklist, and placeholders |
| `latex-template` | User asks for LaTeX templates or filled `.tex` files | Desired output type; manuscript metadata if filling templates | Template paths or filled `.tex` content |
| `appeal-like` | User wants to challenge rejection or process rather than revise | Decision letter and disputed points | Route out of default workflow and explain separate appeal handling |

If the mode is unclear, infer the safest useful mode. Prefer `triage-only` when drafting would
require many unsupported facts.

## Readiness states

Use one readiness state for each comment and one package-level state:

| State | Meaning | Allowed output |
|---|---|---|
| `ready_to_submit` | Direct answer, supplied action, and traceable manuscript location are all present | Final response wording without unresolved placeholders |
| `draft_with_placeholders` | A useful draft can be written, but visible placeholders remain | Draft wording with bracketed placeholders and risk flags |
| `needs_author_input` | Final text would require facts the user has not supplied | Tracker, questions, partial draft only if placeholders are explicit |
| `blocked` | Ethics, compliance, data integrity, missing central evidence, or appeal-like routing prevents credible revision response | Blocking issue first; do not produce confident final wording |

Do not call a package `ready_to_submit` if any comment remains `draft_with_placeholders`,
`needs_author_input`, or `blocked`.

## Editor instruction handling

When editor instructions are supplied:

- Assign editor-level IDs before reviewer IDs: `E.1`, `E.2`, `E.3`.
- Address editor instructions before Reviewer 1, Reviewer 2, etc.
- If editor instructions conflict with reviewer suggestions, surface the conflict in the strategy summary.
- Treat explicit editor constraints as higher priority than reviewer-level preference.

Example:

```text
E.1: Focus on clarifying the central claim without substantial manuscript expansion.
R1.1: Make the causal claim stronger.
R2.1: Soften unsupported causal language.
```

The response strategy should explain that the editor's constraint and the observational design
support claim softening rather than stronger causal language.

## Pasted editorial email handling

When the user pastes an editorial decision email or revision invitation, do not ask them to
separate the email manually. Start by extracting:

- journal name;
- manuscript title and manuscript ID;
- decision type and revision deadline;
- required files, such as clean manuscript, marked manuscript, response to reviewers, cover letter, graphical abstract, data availability update, or supplementary files;
- editor instructions and portal-specific constraints;
- reviewer-report boundaries and comment numbering.
- reviewer-visibility rules and whether the portal accepts separate reviewer-response files.

Ignore boilerplate only after checking it for required files, deadlines, formatting constraints,
and resubmission instructions. If the email contains reviewer reports, enter `revision-package`
or `draft` mode automatically depending on whether the user requested a full package or only a
response letter. If reviewer boundaries are ambiguous, keep the original ordering visible in the
internal package and flag the ambiguity instead of inventing identities. Do not create outward-facing
reviewer files until their boundaries can be separated safely.

## Minimum information by output type

### Full draft response

Requires:

- reviewer comments or editor comments;
- enough author notes to know which actions were taken;
- manuscript locations or placeholders for claimed changes.

If locations are missing, use section names or bracketed placeholders. Do not invent line numbers.

### Final submission-ready response

Requires:

- all reviewer and editor comments identified;
- all claimed actions supplied by the author;
- traceable locations for every manuscript change;
- real details for experiments, analyses, statistics, citations, figures, tables, supplements, ethics, and data availability.

If any required fact is missing, the output is not `ready_to_submit`.

### Audit

Requires:

- user draft;
- reviewer comments when available.

If reviewer comments are absent, audit only the visible draft and flag that completeness cannot be verified.

## Clarifying question rules

Except for the mandatory decision-type gate above, usually proceed with placeholders and risk
flags. Ask concise questions only when:

- Major/Minor Revision status is not supplied and cannot be extracted from the decision letter;
- the user explicitly asks for final submission-ready text and required facts are missing;
- the draft would otherwise fabricate data, locations, approvals, statistics, citations, or figure panels;
- reviewer boundaries are too ambiguous to assign stable IDs;
- the case appears appeal-like or outside normal revision response.

When asking, keep questions specific. Ask the decision-type question first when it is unresolved;
after that, group only the remaining facts that genuinely block the requested output:

```text
I need three facts before final wording: the validation result summary, the Methods/Results location,
and whether Fig. 5 is a main or supplementary figure.
```

## Routing shortcuts

- Vague author note such as "we fixed it" -> `needs_author_input`.
- Existing response with hostile language -> `audit` or `revise`.
- Reviewer asks for impossible new work -> normal revision mode with `PARTIAL` or `OUT_OF_SCOPE`, not appeal.
- Rejection challenge -> `appeal-like`.
- User asks only "what should we do?" -> `triage-only`.
- Pasted decision/revision email with reviewer reports -> auto-parse the email and begin `draft` or `revision-package`; do not wait for the user to reformat the email.

# LaTeX templates for revision correspondence

Use this file when the user asks for a LaTeX cover letter, LaTeX response-to-reviewers
letter, rebuttal `.tex`, red-marked revised manuscript, or a complete revision
package in LaTeX.

## Templates

| Template | Use for |
|---|---|
| `templates/cover-letter.tex` | Editor-facing revision cover letter |
| `templates/response-to-reviewers.tex` | Standalone point-by-point response for one mutually blind reviewer; fill one copy per reviewer |
| `templates/revised-manuscript-redline.tex` | Backed-up manuscript copy with changed text marked in red |

## Filling rules

1. Copy the relevant template content and replace placeholders only when the user
   supplied the fact.
2. Keep visible placeholders such as `Manuscript ID to be supplied` for unknown
   manuscript ID, editor name, author list, line numbers, figure panels, dates,
   or unresolved manuscript changes.
3. Escape LaTeX-sensitive characters in user content: `&`, `%`, `$`, `#`, `_`,
   `{`, `}`, `~`, `^`, and backslash.
4. Keep reviewer comments faithful. If comments are long, preserve the quoted
   comment in the response document and summarize only in tracker tables.
5. Use `\ReviewerComment{...}` and `\AuthorResponse{...}` blocks in the response
   template for each numbered item.
6. After answering a reviewer comment, put any pasted revised manuscript text in
   `\RevisedExcerpt{...}` so it appears in italics.
7. Fill one copy of the response template per reviewer. Do not combine mutually blind reviewer
   reports in one outward-facing `.tex` file.
8. When editing manuscript text, work on a backup/copy of the original manuscript
   and wrap changed text in `\revised{...}` so it appears in red.
9. Do not move unresolved issues into LaTeX comments; they must remain visible in
   the compiled document.

## Output options

- If the user asks for files, create filled `.tex` files based on the templates.
- If the user asks only for a template, return the template path and summarize
  what placeholders need to be filled.
- If the user asks for cover letter, response, and marked manuscript together,
  use all relevant templates and keep manuscript metadata synchronized.

## QA before delivery

- No invented manuscript ID, editor name, line numbers, figure panels, data
  values, or author facts.
- Every comment assigned to that reviewer appears in that reviewer's response text.
- No response file contains another reviewer's IDs, comments, recommendation, or response wording.
- Repeated concerns are answered fully in each relevant reviewer file rather than cross-referenced across files.
- The cover letter summarizes the revision but does not replace the detailed
  point-by-point response.
- Revised manuscript excerpts pasted in the response letter are italic.
- Each mutually blind reviewer receives a separate LaTeX/print-oriented response file unless explicit journal instructions require a combined submission file.
- Manuscript changes in the backed-up manuscript copy are marked in red.
- LaTeX-sensitive characters from user-provided text are escaped.
- If LaTeX compilation is available, compile once and report any errors.

# Package consistency audit

## Contents

1. [The coupling rule](#1-the-coupling-rule)
2. [Red marking must have a baseline](#2-red-marking-must-have-a-baseline)
3. [Deletions ripple](#3-deletions-ripple)
4. [Counting statements go stale](#4-counting-statements-go-stale)
5. [Location references are volatile](#5-location-references-are-volatile)
6. [Manuscript self-consistency and terminology drift](#6-manuscript-self-consistency-and-terminology-drift)
7. [Etiquette failures that survive editing](#7-etiquette-failures-that-survive-editing)
8. [Delivery gate](#8-delivery-gate)

Use this file when a revision package is being finalized, re-edited after an earlier draft, or
audited before submission. It covers the failures that are **mechanically verifiable** and that
survive an editorial read: the manuscript and the response letter drifting apart, red marking that
misrepresents what changed, numbers that do not reconcile, and terminology that fragments across
rounds.

`qa-checklist.md` asks whether the response is complete, honest, and well-toned. This file asks
whether the shipped files actually agree with each other. Run both.

The core rule: **a revision package is three coupled artifacts** — the marked manuscript, the clean
manuscript, and the response letter. An edit to any one of them can silently invalidate the others.
Never edit the manuscript without re-running the checks below.

## 1. The coupling rule

Response letters quote manuscript text. Every quote is a promise that the manuscript reads exactly
that way. Any later edit to a quoted passage must be mirrored in the letter, or a reviewer
comparing the two finds a mismatch and starts doubting everything else.

Checks:

- Every quoted passage in the letter appears **verbatim** in the expanded manuscript source,
  including statically named `\\input{...}` and `\\include{...}` files.
- Editing a quoted manuscript sentence triggers a letter update in the same commit, not later.
- Whitespace, hyphenation, and unit changes count — `4.5 cm` in the letter against `45 mm` in the
  manuscript is a mismatch.
- Where the letter resolves a cross-reference for readability (`Table \ref{tab:x}` printed as
  `Table 1`), record that substitution with a repeated `--substitution SOURCE=RENDERED` argument so
  the automated check does not flag it every round.

Script the check rather than eyeballing it. Resolve the script relative to this skill directory,
then pass the actual package paths:

```bash
python scripts/check_package_consistency.py \
  --manuscript main.tex \
  --response response.tex \
  --clean main-clean.tex \
  --marked main-marked.tex \
  --substitution 'Table \ref{tab:x}=Table 1'
```

The checker expands existing statically named `\\input` and `\\include` files, normalizes LaTeX and
whitespace, checks the arguments of `\\RevisedExcerpt`, `\\revtext`, and `\\oldtext` against the
manuscript, compares the number of `\\ReviewerComment` and `\\AuthorResponse` blocks, removes
`\\deletedtext` / `\\deleted` passages from the marked copy, and confirms that clean and marked
sources otherwise have the same text after revision markup is removed. Use repeated
`--quote-macro NAME` arguments when a project defines a different quote macro and repeated
`--substitution SOURCE=RENDERED` arguments for deliberate rendered substitutions. Use `--json` for
machine-readable findings. A non-zero exit status means the package still contains a mechanical
mismatch.

Re-run it after **every** manuscript edit. It does not replace compiled-PDF page checks, color
inspection, citation/reference diagnostics, or editorial judgement. Those remain manual gates in
the sections below.

## 2. Red marking must have a baseline

Red means "changed in this revision". The baseline is the **archived original submission**, not
what feels new.

- Keep the submitted version on disk (`main_R0_backup.tex` or equivalent) and diff against it.
- Marking unchanged text red inflates the apparent revision and is caught the moment a reviewer
  opens the marked manuscript.
- Leaving genuinely new text unmarked hides work the reviewer asked for.
- Sentences reworded from the original are a judgement call; be consistent within a package and
  lean toward marking substantive rewording, not cosmetic edits.

When the letter reproduces **existing** manuscript text for the reviewer's convenience, give it a
visually distinct, non-red style (plain italic) and state in the letter preamble that plain italic
means unchanged text. Reproducing unchanged text in the same red italic used for new text is a
misrepresentation even when the surrounding prose is honest.

## 3. Deletions ripple

Removing content is more dangerous than adding it, because the letter keeps describing what is no
longer there. After any deletion, grep the letter for prose that describes the deleted item.

Failure patterns seen in practice:

- A table row is dropped, but the letter still says "the table reports all four factors named by the
  reviewer". Fix the sentence, or point to wherever the fourth factor now lives.
- A citation group is trimmed, and the reference list shrinks in a round where reviewers asked for
  **more** references. Decide whether to explain the net change in the letter.
- A sentence is deleted from the manuscript, but the letter still quotes it and still claims it was
  added in response to a comment.
- A quantity is deleted from a table, but the letter's prose still cites that table as the source.
- Deleting a sentence can orphan the sentence that introduced it — check that the surviving opening
  still refers to something present ("This decomposition is actionable" after the only sentence
  about the decomposition was cut).

## 4. Counting statements go stale

Do not write "two sentences have been added", "three new references", or "the four summary items".
Splitting one sentence into three, or dropping an item, silently falsifies the count, and a reviewer
who counts finds the discrepancy.

Prefer "a short passage", "a dedicated item", "the sentences quoted below". If a count must appear,
verify it against the manuscript at the end of every round.

## 5. Location references are volatile

Page numbers change whenever the manuscript reflows, including from edits far away in the document.
Adding a reference can add a page to the bibliography; shortening a paragraph can pull a section back
a page.

- Re-verify **every** page and section reference in the letter after **every** recompile, not once
  at the end.
- Verify by extracting text per page from the compiled PDF and asserting that the quoted phrase
  actually falls on the claimed page, rather than trusting the number written earlier.
- Section numbers are more stable than page numbers; prefer them when the journal allows.
- Never invent line numbers.

```bash
pdftotext -f 8 -l 8 main.pdf - | grep -c "phrase the letter places on page 8"
```

## 6. Manuscript self-consistency and terminology drift

A revision round is when manuscript-internal drift is both introduced and catchable. Run the full
sweep from `nature-shared/core/consistency-sweep.md`: headline counts that do not reconcile with the
Methods, one metric reported at two precisions, superlatives contradicted by the paper's own tables,
over- and under-claiming, terminology and unit variants accumulated across rounds, and tense
parallelism inside the conclusion items.

Two points are specific to a revision package:

- **Every fix that lands inside red-marked text must be mirrored in the letter's quotes** (section 1).
  A terminology sweep is exactly the kind of low-attention edit that desynchronizes a package,
  because the edits feel too small to be worth re-checking.
- **The letter must not promise text the manuscript lacks.** If the letter says "this point is now
  also stated in the Abstract" and quotes a sentence, that sentence must exist in the abstract. This
  is the single most damaging failure in a response package: it is trivially checkable, and it reads
  as fabricated compliance rather than as an oversight.

A related trap: prose added in response to a comment often restates what the neighbouring sentence
already said, or repeats numbers already given in a table quoted right below it in the letter. After
drafting a response, re-read the manuscript passage in place and cut the restatement.

## 7. Etiquette failures that survive editing

Two wording patterns pass a normal read and still damage the response:

- **"Already" constructions.** "The tested configuration is already specified in Section 2" tells the
  reviewer they failed to read. Reframe as author-side work: "To make these boundaries concrete, we
  reproduce below the sentences of Section 2 that define the tested configuration." See
  `tone-and-stance.md`.
- **Cross-reviewer references.** "This comment coincides with Comment 4 of Reviewer 1 and is
  addressed by the sentences quoted above" breaks isolation. Each reviewer's section must stand
  alone, which means **repeating** the quoted manuscript passage in full under both reviewers. The
  duplication is correct, not redundant. See `difficult-cases.md`.

## 8. Compile and delivery gate

- The marked and clean manuscripts must differ **only** in color. Verify with a full text diff of the
  two PDFs, not by inspection.
- Generate the clean copy by toggling the mark-up macro, never by hand-deleting markers.
- Colored table or figure environments need their color removed separately from the mark-up macro.
- Confirm the clean copy actually has no colored text by rendering the page with the most red and
  checking it, since a text diff cannot see color.
- Compile both files with the project's own engine; do not silently substitute one.
- Zero compile errors, zero undefined citations, zero undefined references.
- Bibliography entry count matches expectations after any citation change.
- Every reviewer comment has exactly one response — assert the counts match per reviewer.

## 9. Audit order

Run in this order; later steps depend on earlier ones being stable.

1. Manuscript self-consistency and terminology sweep (section 6, and the shared sweep it points to) — fix content before formatting, and repeat until a pass finds nothing new.
2. Sync every letter quote affected by step 1 (section 1).
3. Recompile.
4. Re-verify page and section references (section 5).
5. Re-run the verbatim quote check (section 1).
6. Etiquette and isolation pass (section 7).
7. Generate the clean copy and run the delivery gate (section 8).
8. Package.

Steps 3 to 5 repeat after every subsequent edit, however small. An edit that removes one sentence
changes pagination, which invalidates the page references verified in the previous round.

# QA checklist

## Contents

- [Completeness](#completeness)
- [Status calibration](#status-calibration)
- [Traceability](#traceability)
- [Revision formatting](#revision-formatting)
- [Reviewer isolation](#reviewer-isolation)
- [Factuality](#factuality)
- [Tone](#tone)
- [Actionability](#actionability)
- [Final output gate](#final-output-gate)
- [Readiness gate](#readiness-gate)


Use this checklist before finalizing a response package or when auditing an existing draft.

## Completeness

- Every reviewer comment has a stable ID.
- Every ID has a response or an explicit unresolved flag.
- No reviewer comment is paraphrased in a way that changes meaning.
- Repeated concerns are answered fully in every relevant reviewer-specific response rather than cross-referenced across reviewers.
- No major concern is answered only with thanks.
- Editor-specific instructions are addressed before reviewer comments when supplied.
- Every editor/reviewer item has an action, work status, required input, expected output, and finalization-blocking state.

## Status calibration

- `VERIFIED_DONE` is supported by an inspectable revised manuscript passage, result, figure/table, repository record, approval, or equivalent supplied artifact.
- An author statement without the corresponding artifact is `REPORTED_DONE_UNVERIFIED`.
- A drafted response paragraph alone never proves that a manuscript change, analysis, or experiment was completed.
- `NOT_FEASIBLE` includes a scientific, ethical, scope, or data-based rationale and an appropriate alternative such as claim moderation or a limitation.
- `PROPOSED_DISAGREEMENT` includes evidence and awaits author confirmation; it is not silently treated as an approved final response.
- Required inputs and expected outputs are concrete enough for the author to act on and verify.
- `Blocks finalization?` agrees with severity, missing evidence, and package readiness.

## Traceability

- Every claimed revision has a manuscript location or visible placeholder.
- Every new figure, table, panel, supplement, or citation is named only if supplied.
- Every new experiment or analysis has enough supplied description to be credible.
- Line numbers are not invented; use section names if line numbers are unavailable.
- Reviewer comments and response IDs match throughout tracker, letter, and checklist.

## Revision formatting

- If manuscript text is edited, the changed text is marked in red on a backed-up/copy version of the original manuscript, with a clean copy kept separate when needed.
- In LaTeX marked manuscripts, changed text uses `\revised{...}` or an equivalent visible red-text macro.
- If revised manuscript text is pasted into the response letter after the answer, that pasted text is italic.
- In LaTeX response letters, pasted revised manuscript excerpts use `\RevisedExcerpt{...}` or another visible italic excerpt style.
- One LaTeX or print-oriented response file is created per mutually blind reviewer unless explicit journal instructions require a combined file.
- Cover letters summarize the revision for the editor and do not replace the point-by-point response.

## Reviewer isolation

- The internal/editor master is clearly labelled as not reviewer-facing.
- Each reviewer-facing file contains only one reviewer's comments and the author responses to those comments.
- Reviewer-facing files use neutral local numbering such as `Comment 1` and contain no IDs belonging to another reviewer.
- No reviewer-facing text says "as another reviewer noted", "see our response to Reviewer 2", "the other reviewer requested", or equivalent wording.
- Repeated concerns receive a complete standalone answer in each relevant reviewer-specific file.
- Conflicting requests are reconciled in the internal/editor strategy, then explained independently to each reviewer without revealing the conflict or the other request.
- Reviewer recommendations, identities, and confidential remarks are never copied into another reviewer's response.
- All reviewer-specific responses describe manuscript changes consistently.
- Explicit journal or portal visibility instructions are followed and any forced combined-file constraint is flagged.

## Factuality

- No invented data.
- No invented p-values, confidence intervals, effect sizes, sample sizes, or replicate counts.
- No invented DOI, citation metadata, accession number, repository record, or figure panel.
- No invented reviewer identity or editor instruction.
- No unsupported claim that an experiment, analysis, or manuscript revision was performed.
- Unsupported claims are softened or flagged.

## Tone

- No avoidable em dash, en dash, or colon is used as a routine sentence connector. Source-faithful
  reviewer quotations and required identifiers or syntax are unchanged.
- No accusations of reviewer incompetence, bias, or misunderstanding unless the user is explicitly preparing an appeal and supplies evidence.
- No excessive apologies.
- No repetitive empty thanks.
- Disagreement is evidence-based and narrow.
- Study limitations are acknowledged cleanly.
- Time, money, convenience, or ability is not the primary stated reason for not doing requested work.
- A missed existing passage is treated as a clarity or visibility problem, not as a reviewer failure.
- No response says "we already stated this", "this was already explained", "as clearly described", or an equivalent rebuke.
- When existing material answers the concern, the response gives a direct answer, a supported clarification, and the final manuscript location or a visible placeholder.

## Actionability

- Missing author inputs are concrete.
- High-risk and blocking items appear before the final letter or in a visible risk section.
- The manuscript change checklist tells the author which section, figure, table, supplement, or claim needs attention.
- Partial responses state what was addressed and what remains unresolved.

## Final output gate

Before returning final text, ask:

- Can an editor verify every response against a manuscript change, supplied evidence, or explicit limitation?
- Would the response remain professional if included in a transparent peer review file?
- Are all placeholders visible enough that the author cannot accidentally submit fabricated compliance?
- Is the package readiness honestly labelled as `ready_to_submit`, `draft_with_placeholders`, `needs_author_input`, or `blocked`?
- If any item is `draft_with_placeholders`, `needs_author_input`, or `blocked`, the package must not be labelled `ready_to_submit`.
- Does every `VERIFIED_DONE` item cite its verification evidence?
- Has each reviewer-facing deliverable passed the isolation checks without relying on another reviewer's response?
- Does `ready_to_submit` have no blocking item, no unresolved placeholder, and no claimed change left at `REPORTED_DONE_UNVERIFIED` or `TODO_*`?

## Readiness gate

Use these labels consistently:

- `ready_to_submit`: all comments are answered, no item blocks finalization, every claimed completed change is verified against supplied evidence, and no placeholder remains.
- `draft_with_placeholders`: draft text exists, but visible placeholders or missing locations remain.
- `needs_author_input`: the author must provide facts before final response wording is credible.
- `blocked`: a compliance, integrity, central-evidence, or appeal-like issue prevents normal final response drafting.

# Response structure

## Contents

- [Default package](#default-package)
- [Response strategy summary](#response-strategy-summary)
- [Internal/editor comment-response tracker](#internaleditor-comment-response-tracker)
- [Reviewer-specific point-by-point letter anatomy](#reviewer-specific-point-by-point-letter-anatomy)
- [Comment 1](#comment-1)
- [Revision cover letter anatomy](#revision-cover-letter-anatomy)
- [Marked manuscript changes](#marked-manuscript-changes)
- [LaTeX deliverables](#latex-deliverables)
- [Manuscript change checklist](#manuscript-change-checklist)
- [Missing information / risk flags](#missing-information-risk-flags)


Use this file when drafting or auditing the output shape of a reviewer response package, revision cover letter, marked manuscript changes, or combined revision correspondence package.

## Default package

Return the response in this order unless the user asks for another format:

1. Internal/editor response strategy summary, clearly marked as not reviewer-facing.
2. Internal/editor comment-response tracker, clearly marked as not reviewer-facing.
3. One standalone privacy-filtered point-by-point response file per reviewer.
4. Draft revision cover letter when requested or when returning a complete revision package.
5. Marked manuscript changes when the user asks to edit the manuscript.
6. LaTeX deliverables when requested.
7. Manuscript change checklist.
8. Missing information / risk flags.
9. Chinese confirmation notes when the user writes in Chinese.

Reviewer reports are mutually blind by default. The master summary and tracker may contain all
reviewers for author/editor coordination, but they must never be passed off as reviewer-facing
documents. If explicit current journal or submission-portal instructions require one combined
response file, follow that requirement and flag the resulting visibility constraint. Otherwise,
produce separate outward-facing files.

## Response strategy summary

Keep this short and editor-readable:

```text
Response strategy summary
- Decision type: Major revision
- Task mode: draft
- Parsed email metadata: manuscript ID and deadline found; required files include response letter and marked manuscript
- Package readiness: draft_with_placeholders
- Overall posture: Cooperative, evidence-forward, non-defensive
- Major risks: missing validation results; unclear replicate definition
- Suggested package: editor master plus separate Reviewer 1 and Reviewer 2 responses
```

Decision types:

- `minor revision`
- `major revision`
- `revise-and-resubmit`
- `transfer after review`
- `appeal-like case` routed outside the default workflow
- `unclear` only as an intake state; ask the user before normal response strategy or prose drafting

Task modes:

- `draft`
- `audit`
- `revise`
- `triage-only`
- `cover-letter`
- `revision-package`
- `latex-template`
- `appeal-like`

Package readiness:

- `ready_to_submit`: no unresolved placeholders or missing facts remain.
- `draft_with_placeholders`: usable draft, but visible placeholders remain.
- `needs_author_input`: final text depends on facts the author has not supplied.
- `blocked`: credible revision response is blocked by ethics, compliance, data integrity, central evidence, or appeal-like routing.

## Internal/editor comment-response tracker

Use a compact table:

```markdown
| ID | Reviewer concern | Type | Severity | Proposed action | Work status | Required input | Expected output | Blocks finalization? |
|---|---|---|---|---|---|---|---|---|
| R1.1 | Missing validation cohort | Evidence / validation | Major | ACCEPT_ANALYSIS | TODO_ANALYSIS | Validation result and location | Results text plus validation table | Yes |
```

Keep reviewer concern text short in the tracker. Preserve the full wording in the letter when available.
Label the tracker `Internal/editor master (not reviewer-facing)`. It may record cross-reviewer
duplicates and conflicts because it is used for coordination and consistency checks.
Use `E.1`, `E.2`, etc. for editor instructions and list them before reviewer comments.
When the input is a pasted editorial email, use the tracker to preserve all extracted required
revision items rather than only the reviewer comments.
Do not use `Work status` as a synonym for `Proposed action`: the former reports progress and verification, while the latter states the response strategy.
If the table becomes too wide for the requested medium, keep the same fields in a per-item block rather than dropping status, expected output, or blocking state.

## Reviewer-specific point-by-point letter anatomy

Create one file per reviewer. Use neutral local numbering so the outward-facing file does not
leak the internal reviewer index or another reviewer's IDs:

```markdown
Dear Reviewer,

We thank you for your careful evaluation of our manuscript.
We have revised the manuscript to address your comments and provide a point-by-point response below.

## Comment 1

**Reviewer comment**
[Full reviewer comment preserved here.]

**Response**
We thank the reviewer for raising this point. [Direct answer.]
To address this concern, we have [specific action]. This change appears in [section/page/line/figure].
[If pasting revised manuscript text, place it after the answer and format it in italics.]

**Revised manuscript text**
*[Paste revised manuscript text here.]*
```

Each reviewer-specific file must contain only that reviewer's comments and responses. It must not
mention another reviewer, quote another report, disclose another recommendation, use another
reviewer's IDs, or refer the reader to another response file. If multiple reviewers raise the same
concern, repeat the complete answer in each relevant file.

## Revision cover letter anatomy

Use the cover letter only when the user asks for it, the journal requires it, or the user asks for a complete revision package. Keep it shorter than the point-by-point response.

```markdown
Dear [Editor name],

Thank you for considering our revised manuscript, "[Manuscript title]" ([Manuscript ID]).
We appreciate the editor's and reviewers' constructive feedback.

In this revision, we have [major revision action 1], [major revision action 2], and [major revision action 3].
These changes address the main concerns regarding [concern/theme 1], [concern/theme 2], and [concern/theme 3].

We provide a detailed point-by-point response to all editor and reviewer comments below / in the accompanying response document.
We believe the revised manuscript is now clearer and better supported, and we hope it will be suitable for further consideration by [Journal name].

Sincerely,
[Corresponding author name]
on behalf of all authors
```

Do not use the cover letter to argue around unresolved reviewer concerns. If a major request remains unresolved, mention that the response letter explains the limitation.

## Marked manuscript changes

When modifying manuscript text, work on a copy of the original manuscript and mark changed passages in red. For LaTeX manuscripts, wrap changed text in `\revised{...}` from `templates/revised-manuscript-redline.tex`. For non-LaTeX outputs, use a clear red-text convention appropriate to the target format and keep a clean version separate from the marked copy.

In the response letter, after the direct answer, paste the revised manuscript text in italics. In LaTeX response files, use `\RevisedExcerpt{...}`.

## LaTeX deliverables

When the user asks for LaTeX, use the templates in `templates/`:

- `templates/cover-letter.tex` for revision cover letters.
- `templates/response-to-reviewers.tex` for point-by-point responses.
- `templates/revised-manuscript-redline.tex` for a red-marked manuscript-copy skeleton.

Fill one copy of `templates/response-to-reviewers.tex` per reviewer. Never place multiple mutually
blind reviewer reports into the same outward-facing `.tex` file.

Preserve visible placeholders for unknown manuscript ID, editor name, line numbers, figure panels, dates, or author information. Do not hide missing facts in comments.

## Manuscript change checklist

List manuscript actions, not polite intentions:

```text
Manuscript change checklist
- R1.1: Add validation result summary to Results and cite Fig. 5.
- R1.2: Clarify replicate definition in Methods.
- R2.1: Soften causal claim in Abstract and Discussion.
```

The checklist uses master IDs and therefore belongs in the internal/editor package, not in a
reviewer-facing file.

## Missing information / risk flags

Use specific requests:

```text
Missing information / risk flags
- R1.1: Need validation result direction and effect/performance summary before final wording.
- R1.2: Need test name, replicate unit, sample size, and correction method.
- R2.1: No line numbers supplied; using section names for now.
```

# Source basis

Use this file to keep `nature-response` grounded in primary or near-primary publication
process sources. Source labels distinguish formal policy from journal instructions and editorial
advice.

## Source hierarchy

1. Target journal instructions and the specific editor decision letter.
2. Nature / Nature Portfolio / Springer Nature peer-review and editorial-process pages.
3. Springer Nature editorial advice on rebuttal letters.
4. Local manuscript facts supplied by the author.

If a current journal page conflicts with this file, follow the current journal page.

## Sources and rules

| Source | URL | Source type | Local rule summary |
|---|---|---|---|
| Nature editorial criteria and processes | https://www.nature.com/nature/for-authors/editorial-criteria-and-processes | Formal journal process | Revised papers that need technical work should be accompanied by a point-by-point response to referee comments. Resubmitted manuscripts must seriously address referee criticisms unless the editor says otherwise. |
| Nature transparent peer review information | https://www.nature.com/nature/for-authors/editorial-criteria-and-processes | Formal journal process | For some published original research articles, reviewer comments and author rebuttal material may be available as transparent peer review files. Write response letters as potentially auditable public documents without assuming every rebuttal is published. |
| Nature Electronics editorial process | https://www.nature.com/natelectron/submission-guidelines/editorial-process | Journal instruction | A revision package commonly includes the revised manuscript, a response to each reviewer, and a cover letter. `nature-response` can draft both the point-by-point response and an editor-facing revision cover letter when requested. |
| Springer Nature rebuttal guidance | https://communities.springernature.com/posts/how-to-write-a-rebuttal-letter | Editorial advice | Preserve reviewer comments, respond immediately after each concern, number or clearly separate replies, state where changes appear, and avoid venting, accusations, ignored requests, or distorted paraphrases. |
| Scientific Reviews peer-review policies | https://www.nature.com/scirev/journal-policies/peer-review | Journal policy | Revisions should include point-by-point responses explaining manuscript changes. Appeals and revision responses follow different logic, so appeal-like cases should be routed separately instead of treated as ordinary point-by-point revision responses. |

## Implementation implications

- Point-by-point response is the default structure for revision cases.
- Every referee criticism must be answered, justified, or flagged as unresolved. Cross-references are allowed only within the same reviewer's own response, never across mutually blind reviewers.
- A cover letter is adjacent revision-package material: draft it when the user asks for a cover letter or a complete revision package, but do not duplicate the full point-by-point response inside it.
- The skill should copy or preserve reviewer wording supplied by the user unless the user asks for anonymization or summarization.
- Tone, accuracy, and traceability should meet the standard of material that may later be reviewed by editors, reviewers, or public readers.
- Do not overstate source authority: Springer Nature advice is useful writing guidance, not journal-specific binding policy.

# Tone and stance

## Contents

- [Core posture](#core-posture)
- [Recommended sentence patterns](#recommended-sentence-patterns)
- [Weak or forbidden patterns](#weak-or-forbidden-patterns)
- [Disagreement pattern](#disagreement-pattern)
- [Reviewer misunderstanding pattern](#reviewer-misunderstanding-pattern)
- [Out-of-scope pattern](#out-of-scope-pattern)
- [Claim-strength verbs](#claim-strength-verbs)


Use this file when drafting response prose, rewriting defensive author notes, or deciding how to disagree.

## Core posture

- Cooperative but not submissive.
- Evidence-forward rather than personality-forward.
- Concise enough for editors to audit quickly.
- Respectful to reviewers without hiding scientific limits.
- Transparent about missing information and unresolved risks.

## Recommended sentence patterns

Use these patterns only when the facts support them:

```text
We thank the reviewer for this constructive suggestion.
We agree that the original wording did not make this point sufficiently clear.
We have revised the manuscript to clarify...
To address this concern, we performed...
The new analysis shows...
We have therefore softened the claim from ... to ...
We respectfully disagree with this interpretation because...
Although we agree that this experiment would be valuable, it is outside the scope of the present study because...
We now explicitly acknowledge this limitation in the Discussion.
```

## Weak or forbidden patterns

Do not present these as acceptable final responses:

```text
The reviewer misunderstood...
The reviewer is wrong...
Due to lack of funding, we cannot...
This is beyond our ability...
As everyone knows...
We believe this is sufficient.
We have revised accordingly.
Thank you for the comment.
As Reviewer 2 also noted...
Please see our response to Reviewer 1...
The other reviewer requested the opposite...
We already stated this in the manuscript...
This was already explained in the original submission...
As clearly described in the original manuscript...
```

It is acceptable to thank reviewers, but thanks cannot be the response. Each reply still needs a
direct answer, action, location, or unresolved flag.

Cross-reviewer phrasing is forbidden in reviewer-facing files. If reviewers repeat or conflict on
an issue, coordinate the shared manuscript action in the internal/editor master and explain it
independently to each reviewer.

## Disagreement pattern

Use this order:

1. Acknowledge the concern.
2. State the point of disagreement narrowly.
3. Give manuscript evidence, external evidence, or scope logic.
4. Make a small clarification if the manuscript may have invited confusion.
5. Avoid personalizing the disagreement.

Template:

```text
We appreciate the reviewer raising this issue. We respectfully disagree that [narrow point],
because [evidence or scope reason]. To make this clearer, we have revised [location] to state
that [revised text or placeholder].
```

## Reviewer misunderstanding pattern

Do not write that the reviewer misunderstood or should have noticed existing text. Treat the
missed point as a presentation signal. Answer the question directly, acknowledge that the original
presentation was not sufficiently clear, revise the wording or placement when supported, and give
the final manuscript location.

```text
We appreciate the reviewer raising this point. We agree that the original presentation did not
make [specific point] sufficiently clear. We have therefore revised [section or location] to state
that [revised text or faithful summary].
```

If the author has not supplied a revised passage or approved a change, keep the proposed
clarification visible as `AUTHOR_INPUT_NEEDED`. Do not convert existing text into an invented
claim that the manuscript has already been revised.

## Out-of-scope pattern

When declining a requested experiment or analysis:

```text
We agree that [requested work] would provide an additional test of [claim]. However, the central
conclusion of the present study is based on [existing evidence], and [requested work] would require
[new cohort/system/longitudinal design] beyond the scope of this revision. To avoid overstatement,
we have revised [location] to acknowledge this limitation and now state that [text or placeholder].
```

Use study design, available evidence, and claim boundaries. Do not lead with time, money, or convenience.

## Claim-strength verbs

Prefer calibrated verbs:

- Strong evidence: `demonstrate`, `show`, `establish`
- Moderate evidence: `indicate`, `suggest`, `support`
- Limited or associative evidence: `are consistent with`, `may reflect`, `raise the possibility`

If the reviewer challenges causality and the evidence is associative, soften causal verbs before drafting the response.

#!/usr/bin/env python3
"""Check mechanical consistency across a LaTeX revision package."""

from __future__ import annotations

import argparse
import json
import re
import sys
from dataclasses import asdict, dataclass
from pathlib import Path
from typing import Iterable


DEFAULT_QUOTE_MACROS = ("RevisedExcerpt", "revtext", "oldtext")
MARKUP_MACROS = ("revised", "added", "changed")
DELETION_MACROS = ("deletedtext", "deleted")
INPUT_PATTERN = re.compile(r"\\(?:input|include)\s*\{([^{}]+)\}")


@dataclass(frozen=True)
class Finding:
    code: str
    message: str
    source: str


def read_text(path: Path) -> str:
    return path.read_text(encoding="utf-8", errors="replace")


def read_latex_project(path: Path, ancestors: tuple[Path, ...] = ()) -> str:
    """Read a LaTeX root file and expand existing static input/include files."""
    path = path.resolve()
    if path in ancestors:
        chain = " -> ".join(str(item) for item in (*ancestors, path))
        raise ValueError(f"cyclic LaTeX include detected: {chain}")

    text = strip_comments(read_text(path))

    def expand(match: re.Match[str]) -> str:
        raw_target = match.group(1).strip()
        if not raw_target or "\\" in raw_target:
            return match.group(0)
        target = Path(raw_target)
        if not target.suffix:
            target = target.with_suffix(".tex")
        if not target.is_absolute():
            target = path.parent / target
        if not target.is_file():
            return match.group(0)
        return read_latex_project(target, (*ancestors, path))

    return INPUT_PATTERN.sub(expand, text)


def matching_brace(text: str, opening: int) -> int | None:
    depth = 0
    escaped = False
    for index in range(opening, len(text)):
        char = text[index]
        if escaped:
            escaped = False
            continue
        if char == "\\":
            escaped = True
            continue
        if char == "{":
            depth += 1
        elif char == "}":
            depth -= 1
            if depth == 0:
                return index
    return None


def extract_macro_arguments(text: str, macro_names: Iterable[str]) -> list[tuple[str, str]]:
    names = tuple(dict.fromkeys(macro_names))
    if not names:
        return []
    pattern = re.compile(r"\\(" + "|".join(re.escape(name) for name in names) + r")\s*\{")
    results: list[tuple[str, str]] = []
    for match in pattern.finditer(text):
        opening = match.end() - 1
        closing = matching_brace(text, opening)
        if closing is not None:
            results.append((match.group(1), text[opening + 1 : closing]))
    return results


def unwrap_single_argument_macros(text: str, macro_names: Iterable[str]) -> str:
    names = tuple(dict.fromkeys(macro_names))
    if not names:
        return text
    pattern = re.compile(r"\\(" + "|".join(re.escape(name) for name in names) + r")\s*\{")
    while True:
        match = pattern.search(text)
        if not match:
            return text
        opening = match.end() - 1
        closing = matching_brace(text, opening)
        if closing is None:
            return text
        text = text[: match.start()] + text[opening + 1 : closing] + text[closing + 1 :]


def remove_single_argument_macros(text: str, macro_names: Iterable[str]) -> str:
    names = tuple(dict.fromkeys(macro_names))
    if not names:
        return text
    pattern = re.compile(r"\\(" + "|".join(re.escape(name) for name in names) + r")\s*\{")
    while True:
        match = pattern.search(text)
        if not match:
            return text
        opening = match.end() - 1
        closing = matching_brace(text, opening)
        if closing is None:
            return text
        text = text[: match.start()] + text[closing + 1 :]


def strip_comments(text: str) -> str:
    return re.sub(r"(?<!\\)%.*$", "", text, flags=re.MULTILINE)


def strip_revision_markup(text: str) -> str:
    text = remove_single_argument_macros(text, DELETION_MACROS)
    text = unwrap_single_argument_macros(text, MARKUP_MACROS)
    text = re.sub(r"\\color\s*\{[^{}]*\}", "", text)
    text = re.sub(r"\\textcolor\s*\{[^{}]*\}\s*\{([^{}]*)\}", r"\1", text)
    return text


def normalize_latex(text: str) -> str:
    text = strip_comments(text)
    text = strip_revision_markup(text)
    replacements = {
        r"\%": "%",
        r"\&": "&",
        r"\_": "_",
        r"\#": "#",
        "~": " ",
    }
    for old, new in replacements.items():
        text = text.replace(old, new)
    text = re.sub(r"\\(?:label|ref|pageref|cite|citep|citet)\s*\{[^{}]*\}", " ", text)
    text = re.sub(r"\\[A-Za-z@]+\*?(?:\[[^\]]*\])?", " ", text)
    text = text.replace("{", " ").replace("}", " ")
    return " ".join(text.split())


def check_quotes(
    manuscript_text: str,
    response_text: str,
    response_name: str,
    quote_macros: Iterable[str],
    minimum_quote_length: int,
) -> list[Finding]:
    manuscript = normalize_latex(manuscript_text)
    findings: list[Finding] = []
    for index, (macro, raw_quote) in enumerate(
        extract_macro_arguments(response_text, quote_macros), 1
    ):
        quote = normalize_latex(raw_quote)
        if len(quote) < minimum_quote_length:
            continue
        if quote not in manuscript:
            preview = quote[:120] + ("..." if len(quote) > 120 else "")
            findings.append(
                Finding(
                    code="QUOTE_NOT_IN_MANUSCRIPT",
                    message=f"{macro} quote {index} is not verbatim in the manuscript: {preview}",
                    source=response_name,
                )
            )
    return findings


def check_response_counts(response_text: str, response_name: str) -> list[Finding]:
    comments = len(extract_macro_arguments(response_text, ("ReviewerComment",)))
    responses = len(extract_macro_arguments(response_text, ("AuthorResponse",)))
    if comments == responses:
        return []
    return [
        Finding(
            code="COMMENT_RESPONSE_COUNT_MISMATCH",
            message=f"reviewer comments={comments}, author responses={responses}",
            source=response_name,
        )
    ]


def check_clean_marked(
    clean_text: str,
    marked_text: str,
    clean_name: str,
    marked_name: str,
) -> list[Finding]:
    clean = normalize_latex(clean_text)
    marked = normalize_latex(marked_text)
    if clean == marked:
        return []
    return [
        Finding(
            code="CLEAN_MARKED_TEXT_MISMATCH",
            message="clean and marked manuscripts differ after revision markup is removed",
            source=f"{clean_name} <-> {marked_name}",
        )
    ]


def run_checks(
    manuscript: Path,
    response: Path,
    clean: Path | None = None,
    marked: Path | None = None,
    quote_macros: Iterable[str] = DEFAULT_QUOTE_MACROS,
    minimum_quote_length: int = 40,
    substitutions: Iterable[tuple[str, str]] = (),
) -> list[Finding]:
    manuscript_text = read_latex_project(manuscript)
    response_text = read_latex_project(response)
    for source, rendered in substitutions:
        manuscript_text = manuscript_text.replace(source, rendered)
    findings = check_quotes(
        manuscript_text,
        response_text,
        str(response),
        quote_macros,
        minimum_quote_length,
    )
    findings.extend(check_response_counts(response_text, str(response)))
    if clean is not None and marked is not None:
        findings.extend(
            check_clean_marked(
                read_latex_project(clean),
                read_latex_project(marked),
                str(clean),
                str(marked),
            )
        )
    return findings


def build_parser() -> argparse.ArgumentParser:
    parser = argparse.ArgumentParser(
        description="Check LaTeX response quotes, response counts, and clean/marked equivalence."
    )
    parser.add_argument("--manuscript", type=Path, required=True)
    parser.add_argument("--response", type=Path, required=True)
    parser.add_argument("--clean", type=Path)
    parser.add_argument("--marked", type=Path)
    parser.add_argument(
        "--quote-macro",
        action="append",
        dest="quote_macros",
        help="LaTeX macro whose braced argument is a manuscript quote. Repeat as needed.",
    )
    parser.add_argument("--minimum-quote-length", type=int, default=40)
    parser.add_argument(
        "--substitution",
        action="append",
        default=[],
        metavar="SOURCE=RENDERED",
        help=(
            "Declare a deliberate source-to-rendered substitution used in a response quote, "
            "for example 'Table \\ref{tab:main}=Table 1'. Repeat as needed."
        ),
    )
    parser.add_argument("--json", action="store_true", dest="as_json")
    return parser


def main(argv: list[str] | None = None) -> int:
    parser = build_parser()
    args = parser.parse_args(argv)
    if (args.clean is None) != (args.marked is None):
        parser.error("--clean and --marked must be supplied together")
    if args.minimum_quote_length < 1:
        parser.error("--minimum-quote-length must be positive")

    substitutions: list[tuple[str, str]] = []
    for raw in args.substitution:
        source, separator, rendered = raw.partition("=")
        if not separator or not source or not rendered:
            parser.error("--substitution must use non-empty SOURCE=RENDERED syntax")
        substitutions.append((source, rendered))

    findings = run_checks(
        manuscript=args.manuscript,
        response=args.response,
        clean=args.clean,
        marked=args.marked,
        quote_macros=args.quote_macros or DEFAULT_QUOTE_MACROS,
        minimum_quote_length=args.minimum_quote_length,
        substitutions=substitutions,
    )
    if args.as_json:
        print(json.dumps([asdict(item) for item in findings], ensure_ascii=False, indent=2))
    elif findings:
        for item in findings:
            print(f"{item.code}\t{item.source}\t{item.message}")
    else:
        print("Package consistency checks passed.")
    return 1 if findings else 0


if __name__ == "__main__":
    raise SystemExit(main())

---
name: nature-response
description: >-
  Draft, audit, or revise Nature-style revision correspondence packages: point-by-point
  reviewer-separated response letters, rebuttal letters, revision cover letters, LaTeX
  cover/response templates, and red-marked revised-manuscript excerpts. Keep mutually blind
  reviewers isolated so no reviewer-facing response reveals another reviewer's comments,
  numbering, recommendation, or author response. Prevent reviewer-driven manuscript
  accretion by preferring replacement, compression, or SI relocation over appending
  non-central defense prose. Use for reviewer comments, editor
  decision letters, pasted editorial emails, response drafts, cover letters, response to
  reviewers, rebuttal, 修回信, 返修邮件, 编辑邮件, 返修 cover letter, 审稿意见回复,
  逐点回复, 大修回复, 小修回复, 回复审稿人, 修改稿回复, 写rebuttal, 回应审稿意见,
  标红修改, or LaTeX 模板.
---

# Nature Reviewer Response — Router

This skill is split into two layers:

- A **static layer** under `static/` that holds versioned, reusable content fragments (the default stance and red lines, and the response workflow with output format).
- A **dynamic layer** (this file plus `manifest.yaml`) that loads the core every time and reaches for the deeper response references or templates only when a step needs them.

Do not try to apply the response logic from memory or from this router. Always load fragments from disk as described below.

## Routing protocol

Follow these four steps every time the skill is invoked.

### 1. Load the manifest and the core layer

Read [manifest.yaml](manifest.yaml). Then read every file listed under `always_load`:

- `static/core/stance.md` — the editor-facing purpose, the default stance, the red lines, and the source hierarchy that apply to every response job.
- `static/core/workflow.md` — accepted inputs, the revision correspondence workflow, and the output package format.

### 2. No content axis — identify mode and language inline

Unlike nature-writing or nature-figure, nature-response has no fragment axis. Its variation is identified at runtime, not by loading different content bodies:

- **task mode** — `draft` / `audit` / `revise` / `triage-only` / `cover-letter` / `revision-package` / `latex-template` / `appeal-like`.
- **decision type** — minor revision, major revision, revise-and-resubmit, transfer after review, or unclear.
- **user language** — if the user writes Chinese, also produce the 中文核对 block.

Decision type is a required intake gate for normal revision work. First extract it from an
editor decision letter when available. If it is still unclear, ask the user whether this is a
`Major Revision` or `Minor Revision` before drafting a response strategy or response prose. Do
not infer the decision from the number, tone, or apparent difficulty of reviewer comments.

Use `references/intake-and-routing.md` to fix the task mode, minimum inputs, and readiness state before drafting. Route appeal-like cases separately; do not draft an appeal as the default path.

### 3. Run the workflow

Follow the workflow in `core/workflow.md`: if the user pasted a journal email, first parse manuscript metadata, decision type, editor instructions, reviewer reports, required files, deadlines, and reviewer-visibility rules from the email; identify mode and pass the decision-type gate; apply the Major- or Minor-Revision strategy without downgrading the severity of individual comments; extract editor instructions (IDs `E.1`) then reviewer comments (`R1.1`, `R2.1`) when present; classify each item by response action and independently verified work status; build an internal/editor master strategy and tracker; draft a standalone privacy-filtered response for each mutually blind reviewer; when a reviewer missed material already present in the manuscript, treat that as a clarity signal and revise the presentation instead of replying that the point was already stated; draft a revision cover letter when required; map every claimed change to a manuscript location or explicit placeholder; mark changed manuscript text in red on a backed-up copy when editing; format quoted revised manuscript text in the response letter in italics; flag missing author input; run QA; and derive package readiness from the per-item statuses and blocking state.

Whenever a response proposes or performs a manuscript main-text edit, also load
`../nature-shared/core/main-text-discipline.md`. Answer the reviewer completely
in the letter, but keep the manuscript change to the shortest text needed for
the reader. Prefer replacement or compression over appending, and route
non-central robustness or reconciliation detail to SI unless it changes the
central interpretation.

Never invent experiments, citations, line numbers, figure panels, supplementary items, editor instructions, or manuscript changes. Mark anything the author must supply as `AUTHOR_INPUT_NEEDED`.

### 4. Reach for references only when needed

The files under `references/` and `templates/` are deep resources, not defaults. Open them on demand per the `references.on_demand` table in the manifest — for example `references/comment-taxonomy.md` to classify comments, `references/action-mapping.md` for tracker fields, `references/tone-and-stance.md` for disagreement wording, `references/difficult-cases.md` for impossible experiments / conflicting reviewers / appeal-like cases, `references/chinese-author-alignment.md` for Chinese author notes, `references/latex-templates.md` for `.tex` cover/response/redline outputs, `../nature-shared/core/main-text-discipline.md` for reviewer-driven manuscript additions and evidence relocation, `references/package-consistency-audit.md` whenever the manuscript is edited alongside the letter or the package is about to be compiled and delivered, and `references/qa-checklist.md` before finalizing.

`qa-checklist.md` and `package-consistency-audit.md` are complementary and both apply to a final package: the first asks whether the response is complete, honest, and well-toned; the second asks whether the marked manuscript, the clean manuscript, and the letter actually agree with each other after editing. For a LaTeX package, run `scripts/check_package_consistency.py` after the first complete draft, after every manuscript edit, and immediately before delivery. Any manuscript edit invalidates the letter's verbatim quotes and page references, so re-run the audit rather than treating it as a one-time final check.

## Why this split

- The static layer is versioned and reviewable; the core stays small for a normal response.
- The dynamic layer keeps each invocation cheap: the difficult-case, taxonomy, and QA depth load only when a step needs them.
- The router itself is short on purpose. Update fragments and references, not this file, when adding scope.
- This structure mirrors `nature-writing`, `nature-polishing`, `nature-reader`, `nature-paper2ppt`, `nature-figure`, and `nature-citation`.

# Default stance and red lines

Use this skill to convert editor decision letters, reviewer comments, author notes, draft rebuttals, or revision-summary notes into an auditable revision correspondence package: an internal/editor master tracker, reviewer-separated point-by-point response letters, a revision cover letter, red-marked manuscript changes, or a LaTeX deliverable.

The master tracker is an editor-facing or author-internal verification document. Each reviewer-facing response is a standalone document containing only that reviewer's comments and the corresponding author responses. The cover letter is an editor-facing revision summary. The goal is to show that every reviewer concern has been understood, addressed, and mapped to a concrete manuscript change, justified scientific response, or unresolved author action without disclosing one mutually blind reviewer's material to another.

## Default stance

- Preserve each reviewer comment faithfully before responding.
- Every reviewer concern must be answered or explicitly marked as unresolved. Cross-references may be used within one reviewer's own response but never across reviewers.
- Treat reviewer reports as mutually blind by default. A reviewer-facing file must not reveal another reviewer's comments, numbering, recommendation, identity, response text, or conflicting request.
- Keep a complete internal/editor master tracker for deduplication, conflict handling, and consistency, and label it clearly as not reviewer-facing.
- When multiple reviewers raise the same concern, give each reviewer a complete standalone answer. Do not refer a reviewer to another reviewer's response.
- Map every response to manuscript evidence, a revision location, a justified disagreement, or `AUTHOR_INPUT_NEEDED`.
- Keep response action, per-item work status, and package readiness separate: what should be done is not evidence that it has been done.
- Do not invent experiments, analyses, citations, line numbers, figure panels, supplementary materials, editor instructions, reviewer identities, or manuscript changes.
- Prefer concise, evidence-linked replies over long defensive explanations.
- Avoid em dashes, en dashes, and colons as routine prose punctuation in response letters,
  cover letters, internal summaries, and author notes. Prefer sentence boundaries, commas,
  semicolons, parentheses, or a short heading followed by a new line. Preserve punctuation in
  source-faithful reviewer quotations, titles, formulas, identifiers, URLs, times, and required
  machine-readable syntax.
- When disagreeing, acknowledge the concern first, then give a scientific or scope-based reason.
- When a reviewer misunderstood the manuscript, first consider whether the manuscript presentation caused the misunderstanding.
- When a reviewer missed information that was already present, treat the comment as evidence that the information was not sufficiently visible or clear. Answer the concern directly, improve the wording or placement when supported by the author, and cite the revised location.
- Keep the response letter complete but the manuscript change minimal. For every
  proposed main-text addition, inspect the whole paragraph and prefer
  replacement, compression, or SI relocation before appending.
- Treat rebuttal letters as potentially public review artifacts; write with professional tone and traceability.
- Keep cover letters concise: identify the manuscript, thank the editor/reviewers, summarize major revision actions, and point to the point-by-point response.
- When editing the manuscript text, work on a backup/copy of the original manuscript and mark changed passages in red.
- In the response letter, after answering a comment, any pasted revised manuscript text must be italic.

## Red lines

- Do not ignore any reviewer comment.
- Do not rephrase reviewer comments in a way that changes their meaning.
- Do not claim a revision was made unless the user supplied it.
- Do not mark work as verified merely because a draft reply exists or the author says "done" without an inspectable revised artifact.
- Do not invent line numbers, figure panels, citations, statistical results, or supplementary items.
- Do not use hostile or accusatory language.
- Do not cite time, money, or convenience as the primary reason for not doing a requested experiment.
- Do not hide limitations.
- Do not turn the main text into a pre-emptive reviewer response or bury the
  central evidence chain under robustness and reconciliation prose.
- Do not generate an appeal letter as the default path. Route appeal-like cases separately.
- Do not claim a cover letter, response letter, or marked manuscript is submission-ready while placeholders remain.
- Do not hide missing manuscript changes in comments or unrendered notes.
- Do not write phrases such as "as Reviewer 2 also noted", "see our response to Reviewer 1", or "the other reviewer requested" in a reviewer-facing response.
- Do not include another reviewer's comment IDs or recommendation in a reviewer-facing file.
- Do not use dash punctuation or colons as habitual sentence connectors when clearer sentence
  boundaries or headings work.
- Do not rebuke a reviewer with phrases such as "we already stated this in the manuscript", "this was already explained", or "as clearly described in the original manuscript". Existing text does not excuse unclear presentation.

## Source hierarchy

Use sources in this order:

1. Target journal instructions and the editor decision letter.
2. Nature / Nature Portfolio / Springer Nature revision and peer-review process guidance.
3. Springer Nature editorial advice on rebuttal letters and journal-specific revision-package instructions.
4. Local manuscript facts supplied by the author.

If a policy detail may have changed, verify the current journal page before giving final submission advice.

# Workflow and output format

## Accepted inputs

The skill may receive: pasted editorial decision or revision-invitation email; editor decision letter; reviewer comments; previous response draft; manuscript change notes; tracked-change summary; line or page numbers; figure, table, and supplement list; author notes in Chinese or English; journal name and article type; manuscript title; author list; manuscript ID; original manuscript text or LaTeX source; requested cover-letter or LaTeX output format; journal or portal instructions governing who can see each response file.

If reviewer boundaries or comment segmentation are ambiguous, flag the ambiguity instead of inventing reviewer structure.

## Decision-type gate and revision strategy

For normal revision-response work, determine the editorial decision before drafting the response
strategy or response prose:

1. Use an explicit label in the editor decision letter or revision invitation when supplied.
2. Normalize informal author wording such as `major review` and `minor review` to `Major Revision`
   and `Minor Revision` when the meaning is unambiguous.
3. If the decision remains unclear, ask one concise question in the user's language and pause:
   `这是 Major Revision（大修）还是 Minor Revision（小修）？如果决定信没有明确写，请把决定信发给我，我帮你判断。`
   English default: `Is this a Major Revision or a Minor Revision? If the decision letter does
   not state it clearly, please send it and I can help classify the decision.`
4. Do not infer the decision type from comment count, reviewer tone, requested workload, or the
   apparent severity of individual comments.

After the gate is resolved, use the corresponding default strategy:

| Decision type | Default revision strategy |
|---|---|
| `Major Revision` | Build an evidence-first work plan. Prioritize central-claim support, experiments or analyses, methods and statistics, validation, figures, limitations, and any structural rewriting. Treat unresolved central evidence or integrity/compliance items as finalization blockers. Responses should explain both the action and the evidence that resolves each concern. |
| `Minor Revision` | Use a bounded correction plan. Prioritize precise wording, definitions, citations, reporting details, figure/table presentation, and localized clarifications. Keep replies concise and avoid unnecessary redesign of the study or expansion of claims unless an editor or reviewer request genuinely requires it. |

The decision label sets the package-level posture, not the severity of every comment. A substantive
evidence, statistics, ethics, or data-integrity concern remains major or blocking even inside a
Minor Revision. Journal instructions and explicit editor directions override these defaults.

## Workflow

1. Identify task mode and input readiness: `draft`, `audit`, `revise`, `triage-only`, `cover-letter`, `revision-package`, `latex-template`, or `appeal-like`.
2. If the input is a pasted journal email, automatically extract manuscript title, manuscript ID, journal, decision type, editor instructions, reviewer-report boundaries, required revision files, deadline, reviewer-visibility rules, and portal-specific constraints before drafting.
3. Pass the decision-type gate. For normal revision modes, pause and ask the user when the decision remains unclear; do not draft a generic response that silently treats Major and Minor Revision as equivalent.
4. Select the decision-specific package strategy while preserving item-level severity.
5. Extract editor instructions first and assign IDs such as `E.1`, then split reviewer comments with IDs such as `R1.1`, `R1.2`, and `R2.1`.
6. Classify each item by category, severity, action label, work status, required input, expected output, finalization-blocking state, package readiness, and risk.
7. Create an internal/editor master strategy and tracker before drafting prose. It may record duplicates and conflicts across reviewers, but label it clearly as not reviewer-facing.
8. Treat reviewer reports as mutually blind by default. For each reviewer, draft a standalone privacy-filtered response containing only that reviewer's comments and the author responses to them. Use neutral local labels such as `Comment 1` in outward-facing files. Do not expose another reviewer's IDs, comments, recommendation, identity, response wording, or conflicting request.
9. When reviewers repeat the same concern, answer it fully in every relevant reviewer-specific file. When their requests conflict, reconcile the scientific and manuscript action in the master strategy, then explain the chosen revision independently to each reviewer using only that reviewer's concern and the manuscript evidence.
10. When a reviewer asks about material that already existed in the submitted manuscript, use `CLARIFY_EXISTING` and treat the missed point as a presentation problem. Answer directly, acknowledge that the original wording or placement did not make the point sufficiently clear, make or propose a small clarification, and cite the revised location. Do not say that the reviewer should have seen it or that it was already stated.
11. If explicit current journal or portal instructions require one combined response document, follow that submission requirement and flag its visibility implications. Otherwise default to an editor/internal master plus separate reviewer-specific files. Never silently treat the master tracker as reviewer-facing.
12. For `cover-letter` or `revision-package`, draft a concise editor-facing cover letter that summarizes revision scope and points to the point-by-point responses without duplicating them.
13. Map each claimed change to manuscript location, figure, table, supplement, citation, or explicit placeholder. For every main-text edit, load `../../../nature-shared/core/main-text-discipline.md`, classify the result or explanation, and decide whether it belongs in the main text, caption, Methods/source data, SI, or response letter. Answer the reviewer fully in the letter while keeping the manuscript change to the shortest reader-facing text that preserves the central inference. Every addition triggers a deletion check across the affected paragraph; prefer replacement or compression before appending.
14. If editing manuscript text, create or instruct use of a backed-up manuscript copy and mark changed text in red. For LaTeX, use `\revised{...}` from `templates/revised-manuscript-redline.tex`.
15. If pasting revised manuscript text after a response, format it in italics. For LaTeX response files, use `\RevisedExcerpt{...}` from `templates/response-to-reviewers.tex`.
16. If the user requests LaTeX, create one filled copy of `templates/response-to-reviewers.tex` per reviewer and use `templates/cover-letter.tex` and/or `templates/revised-manuscript-redline.tex` as needed. Preserve visible placeholders for missing facts.
17. Mark a claimed change `VERIFIED_DONE` only after matching it to supplied revised manuscript text, analysis output, figure/table content, or another inspectable artifact. Treat an unsupported author report as `REPORTED_DONE_UNVERIFIED`.
18. Flag missing author input rather than fabricating details.
19. Run QA for completeness, decision-strategy consistency, reviewer isolation, per-item status calibration, blocking-state consistency, traceability, factuality, tone, unresolved risk, red-marked changes, italic revised excerpts, and LaTeX placeholder visibility.
20. Derive package readiness from the item statuses and return one of: `ready_to_submit`, `draft_with_placeholders`, `needs_author_input`, or `blocked`.

## Output format

Unless the user asks for another format, return:

```text
Response strategy summary
- Decision type:
- Task mode:
- Overall posture:
- Major risks:
- Parsed email metadata:
- Suggested ordering:
- Package readiness:

Internal/editor master tracker (not reviewer-facing)
| ID | Reviewer concern | Type | Severity | Proposed action | Work status | Required input | Expected output | Blocks finalization? |
|---|---|---|---|---|---|---|---|---|

Reviewer-specific response files
- Reviewer 1: [standalone response containing Reviewer 1 comments only]
- Reviewer 2: [standalone response containing Reviewer 2 comments only]

Draft revision cover letter
[only when requested or when returning a revision package]

Marked manuscript changes
- [red-marked changed passages or path to marked backup copy]

LaTeX files
- cover letter: [path or template-filled text when requested]
- response to Reviewer 1: [path or template-filled text when requested]
- response to Reviewer 2: [path or template-filled text when requested]
- red-marked manuscript: [path or template-filled text when requested]

Manuscript change checklist
- [specific manuscript changes or placeholders]
- Main-text discipline audit: [result/explanation class; destination; appended,
  replaced, compressed, relocated, or deleted; before/after paragraph word count]

Missing information / risk flags
- [specific unresolved items or "None"]

中文核对
- [when the user writes in Chinese; otherwise omit unless useful]
```

\documentclass[11pt]{letter}

\usepackage[margin=1in]{geometry}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}
\usepackage{hyperref}
\usepackage{setspace}

\signature{Corresponding author name\\on behalf of all authors}
\address{Corresponding author affiliation\\Corresponding author email}
\date{\today}

\begin{document}

\begin{letter}{Editor name\\Journal name}

\opening{Dear Editor name,}

Thank you for considering our revised manuscript entitled
\emph{Manuscript title to be supplied}
(Manuscript ID: Manuscript ID to be supplied) for publication in
\emph{Journal name to be supplied}.

We appreciate the editor's and reviewers' constructive comments. In the revised
manuscript, we have addressed the main concerns by:
\begin{itemize}
  \item Major revision action 1 to be supplied.
  \item Major revision action 2 to be supplied.
  \item Major revision action 3 to be supplied.
\end{itemize}

These revisions clarify the manuscript's contribution, strengthen the evidence
supporting the central claims, and improve the presentation for the journal's
readership. A detailed point-by-point response to each editor and reviewer
comment is provided in the accompanying response document.

We hope that the revised manuscript is suitable for further consideration by
\emph{Journal name to be supplied}. Thank you for your time and consideration.

\closing{Sincerely,}

\end{letter}

\end{document}

\documentclass[11pt]{article}

% Privacy rule: fill one copy of this template for one mutually blind reviewer.
% Do not add comments, identifiers, recommendations, or responses from another reviewer.

\usepackage[margin=1in]{geometry}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}
\usepackage{hyperref}
\usepackage{xcolor}
\usepackage{setspace}

\newcommand{\ReviewerComment}[1]{%
  \par\noindent\textbf{Reviewer comment}\par
  \begin{quote}\itshape #1\end{quote}
}

\newcommand{\AuthorResponse}[1]{%
  \par\noindent\textbf{Response}\par
  #1\par
}

\newcommand{\RevisedExcerpt}[1]{%
  \par\noindent\textbf{Revised manuscript text}\par
  \begin{quote}\itshape #1\end{quote}
}

\newcommand{\ManuscriptChange}[1]{%
  \par\noindent\textbf{Manuscript change}\par
  #1\par
}

\title{Response to Reviewer\\
\large Manuscript title to be supplied}
\author{Corresponding author name on behalf of all authors}
\date{\today}

\begin{document}
\maketitle

\noindent\textbf{Journal:} Journal name to be supplied\\
\textbf{Manuscript ID:} Manuscript ID to be supplied\\
\textbf{Decision type:} Major revision / minor revision / revise and resubmit to be supplied

\section*{Opening response}

We thank you for your careful evaluation of our manuscript.
We have revised the manuscript to address your comments and provide a
point-by-point response below.

\section*{Comment 1}
\ReviewerComment{Full reviewer comment 1 to be supplied.}
\AuthorResponse{We thank the reviewer for raising this point. Direct response and supporting evidence to be supplied.}
\RevisedExcerpt{Paste the revised manuscript text here. This excerpt is intentionally italic.}
\ManuscriptChange{Manuscript change location, figure, table, supplement, or explicit placeholder to be supplied.}

\section*{Comment 2}
\ReviewerComment{Full reviewer comment 2 to be supplied.}
\AuthorResponse{Response to comment 2 to be supplied.}
\RevisedExcerpt{Revised manuscript text for comment 2 to be supplied.}
\ManuscriptChange{Manuscript change for comment 2 to be supplied.}

\end{document}

\documentclass[11pt]{article}

\usepackage[margin=1in]{geometry}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}
\usepackage{xcolor}
\usepackage{hyperref}
\usepackage[normalem]{ulem}

\newcommand{\revised}[1]{\textcolor{red}{#1}}
\newcommand{\deletedtext}[1]{\textcolor{red}{\sout{#1}}}

% Use this file as a marked backup/copy of the original manuscript.
% Copy the original manuscript text here, then wrap changed passages in
% \revised{...}. Do not use this as the clean submission copy unless the journal
% explicitly requests a marked version.

\title{Marked Revised Manuscript\\
\large Manuscript title to be supplied}
\author{Author list to be supplied}
\date{\today}

\begin{document}
\maketitle

\section*{Marked revision note}

This document is a marked copy of the original manuscript. Text changed during
revision is shown in red. A separate clean manuscript should be prepared for
submission unless the journal requests a marked copy.

\section{Introduction}

Original manuscript text to be supplied. Example revised sentence:
\revised{This sentence represents revised manuscript text and is marked in red.}

\section{Methods}

Original methods text to be supplied.

\section{Results}

Original results text to be supplied.

\section{Discussion}

Original discussion text to be supplied.

\end{document}

# Test: conflicting reviewers

## Input

```text
Editor decision: Major revision.

Editor:
Please avoid expanding the manuscript substantially; focus on clarifying the central claim and
addressing the reviewers' concerns with existing data where possible.

Reviewer 1:
1. The abstract should make a stronger causal claim that X drives Y.

Reviewer 2:
1. The causal language is not supported by the current observational design and should be softened.

Author notes:
- The study is observational.
- We can soften the abstract and discussion.
- We can add a sentence explaining that the findings support an association, not causality.
```

## Expected behavior

- Assign editor instruction ID `E.1` and address it before reviewer comments.
- Assign reviewer IDs `R1.1` and `R2.1`.
- Detect a conflict between Reviewer 1 and Reviewer 2 in the internal/editor master only.
- Prioritize the editor instruction and the evidentiary limit of the observational design.
- Use `SOFTEN_CLAIM` for `R2.1`.
- Use `PARTIAL` or `DISAGREE` for the stronger causal-claim request in `R1.1`, with respectful reasoning.
- Avoid incompatible promises.
- Produce separate Reviewer 1 and Reviewer 2 response files.
- Explain the chosen association-only wording independently to each reviewer without disclosing the other request.
- Mark readiness as `draft_with_placeholders` unless exact revised abstract/discussion wording or locations are supplied.

## Forbidden behavior

- Do not promise both stronger causal language and softened causal language.
- Do not ignore the editor instruction.
- Do not claim causality from an observational design.
- Do not accuse either reviewer of being wrong.
- Do not invent revised abstract or discussion line numbers.
- Do not tell Reviewer 1 that Reviewer 2 requested softer wording.
- Do not tell Reviewer 2 that Reviewer 1 requested stronger wording.
- Do not cross-reference `R1.1` from the Reviewer 2 response or `R2.1` from the Reviewer 1 response.

## Pass/fail checklist

- [ ] `E.1` appears in the tracker or strategy summary.
- [ ] The conflict is surfaced explicitly in the internal/editor master and nowhere in reviewer-facing files.
- [ ] The chosen response is consistent with the observational design.
- [ ] `R1.1` and `R2.1` are both answered.
- [ ] No incompatible manuscript-change promises appear.
- [ ] Each reviewer receives a complete standalone response using only that reviewer's concern.
- [ ] Neither reviewer-facing file reveals the other reviewer's comment, ID, recommendation, or response.

# Test: defensive draft audit

## Input

```text
Mode requested: audit and revise this draft response.

Reviewer 1:
1. The method description is unclear and does not explain how model calibration was performed.
2. The authors should report the software version.

Author draft:
The reviewer clearly misunderstood our method. We already explained the calibration in the paper.
We have revised accordingly. The software version is now included.

Author notes:
- Calibration is described in Methods, but the exact paragraph may not be clear.
- Software version: v2.3.1.
- No line numbers are available yet.
```

## Expected behavior

- Detect task mode as `audit` or `revise`.
- Assign stable IDs `R1.1` and `R1.2`.
- Flag the author draft as defensive and insufficiently traceable.
- Rewrite the misunderstanding sentence as manuscript-clarity framing.
- Remove "We already explained the calibration in the paper" as impolite reviewer-facing language.
- Treat `R1.1` as `CLARIFY_EXISTING` plus possible `ACCEPT_TEXT`.
- Treat `R1.2` as `ACCEPT_TEXT` with supplied version `v2.3.1`.
- Use section names rather than invented line numbers.
- Mark package readiness as `draft_with_placeholders` or `needs_author_input` until exact Methods location or revised text is supplied.

## Forbidden behavior

- Do not retain "The reviewer clearly misunderstood our method."
- Do not retain "We already explained the calibration in the paper" or replace it with equivalent wording such as "as clearly stated in the manuscript".
- Do not retain bare "We have revised accordingly."
- Do not invent line numbers or a Methods paragraph.
- Do not claim the calibration explanation was already sufficient without clarifying the manuscript.
- Do not remove the supplied software version.

## Pass/fail checklist

- [ ] Defensive language is removed.
- [ ] The response does not tell the reviewer that the point was already present or should have been noticed.
- [ ] Each reviewer comment receives its own ID.
- [ ] Revised response includes manuscript-clarity framing.
- [ ] The response directly explains the calibration point and proposes or cites a clearer Methods presentation.
- [ ] `v2.3.1` is preserved exactly.
- [ ] Missing location details remain visible.

# Evaluation summary

`nature-response` is evaluated with synthetic Markdown fixtures. These tests are not executable
unit tests; they are behavior contracts for manual and agent review.

## Status rationale

Recommended status: `Beta`.

Rationale:

- The core rules are defined in `SKILL.md` and modular references.
- The skill has synthetic fixtures covering mandatory decision-type intake, minor revision, major
  revision with missing evidence, impossible experiment, defensive draft audit, conflicting
  reviewers, mutually blind reviewer-response separation, and per-task status tracking.
- Each fixture includes expected behavior, forbidden behavior, and pass/fail criteria.
- The examples show expected output shape without using real confidential reviewer comments.
- The skill has not yet been validated on real anonymized revision packages, so `Stable` would be premature.

## Fixture coverage

| Fixture | Coverage | Key failure prevented |
|---|---|---|
| `unclear-decision-type.md` | mandatory Major/Minor intake gate | guessing the revision type or drafting with the wrong package strategy |
| `minor-revision.md` | stable IDs, minor comments, missing citation metadata | fabricated citation or line numbers |
| `major-revision-missing-evidence.md` | validation request, statistical details, missing evidence | invented results or p-values |
| `impossible-experiment.md` | out-of-scope longitudinal evidence | time/funding excuse or fabricated survival data |
| `defensive-draft-audit.md` | hostile draft language, missed existing text, vague compliance | accusatory wording or an impolite "we already stated this" reply |
| `conflicting-reviewers.md` | editor priority, incompatible reviewer requests, and reviewer isolation | contradictory promises or cross-reviewer disclosure |
| `reviewer-visibility.md` | separate outward-facing responses for mutually blind reviewers | leaked comments, IDs, recommendations, or cross-review references |
| `task-status-tracking.md` | action/status separation, verification evidence, expected output, blocking state | false completion and premature submission readiness |

## Manual evaluation checklist

- [x] Every fixture has input, expected behavior, forbidden behavior, and pass/fail checklist.
- [x] No fixture uses real reviewer comments.
- [x] Examples are synthetic and do not contain confidential review content.
- [x] Status remains below `Stable` until real anonymized cases are reviewed.

## Promotion path to Stable

Promote from `Beta` to `Stable` only after:

- at least two real anonymized revision packages are tested with author permission;
- no fabricated actions, line numbers, statistics, or citations are observed;
- Chinese-note workflows produce usable English response drafts and Chinese confirmation notes;
- edge cases such as conflicting reviewers and impossible experiments remain traceable.

# Test: impossible experiment

## Input

```text
Editor decision: Major revision.

Reviewer 2:
1. Please add 2-year survival outcomes to support the clinical relevance of the biomarker.

Author notes:
- The study is cross-sectional.
- We do not have longitudinal follow-up.
- We can soften the claim and add a limitation in the Discussion.
- We can point to the existing association analysis in Figure 3.
```

## Expected behavior

- Assign stable ID `R2.1`.
- Classify the request as evidence / interpretation plus scope / feasibility.
- Use `PARTIAL` or `OUT_OF_SCOPE` with a high-risk flag, not simple refusal.
- Acknowledge the scientific value of longitudinal survival data.
- Explain that 2-year survival requires longitudinal follow-up beyond the present cross-sectional design.
- Offer the supplied alternative evidence: existing association analysis in `Figure 3`.
- Add a limitation / softened claim action in the Discussion.

## Forbidden behavior

- Do not cite time, money, convenience, or lack of funding as the primary reason.
- Do not say the experiment is impossible without explaining the study-design boundary.
- Do not imply survival data were collected.
- Do not accuse the reviewer of asking for an unreasonable experiment.
- Do not leave the central claim unchanged if the requested evidence is absent.

## Pass/fail checklist

- [ ] The response acknowledges the value of the requested survival evidence.
- [ ] The scope boundary is scientific and design-based.
- [ ] The response includes alternative evidence from `Figure 3`.
- [ ] The manuscript checklist includes claim softening or limitation text.
- [ ] No fabricated survival results appear.

# Test: major revision with missing evidence

## Input

```text
Editor decision: Major revision.

Reviewer 1:
1. The manuscript requires validation in an independent cohort.
2. The statistical replicate definition is unclear.

Author notes:
- We added validation using dataset GSEXXXX and placed it in new Fig. 5.
- We fixed the statistics description.
- Please write the reply in Nature style.
```

## Expected behavior

- Assign stable IDs: `R1.1`, `R1.2`.
- Classify `R1.1` as major evidence / validation with `ACCEPT_ANALYSIS` or `ACCEPT_EXPERIMENT`, depending on whether dataset validation is presented as analysis or experiment.
- Mention dataset `GSEXXXX` and `Fig. 5` because the author supplied them.
- Flag missing result details for `R1.1`, such as outcome direction, performance/effect summary, sample count if relevant, and manuscript section or line location.
- Classify `R1.2` as statistical / methodological and flag missing exact details.
- Request the statistical test name, replicate unit, sample size or replicate count, correction method when relevant, and Methods location.

## Forbidden behavior

- Do not invent validation results, performance numbers, p-values, confidence intervals, sample sizes, or effect sizes.
- Do not claim "the revised Methods now states" unless revised text or location is supplied.
- Do not treat "We fixed the statistics description" as enough evidence for a final confident response.
- Do not downgrade a major validation request to minor wording.

## Pass/fail checklist

- [ ] Major risks are surfaced in the strategy summary.
- [ ] `GSEXXXX` and `Fig. 5` are preserved exactly.
- [ ] Missing evidence is marked as `AUTHOR_INPUT_NEEDED`.
- [ ] Statistical details are requested explicitly.
- [ ] No fabricated quantitative results or manuscript locations appear.

# Test: minor revision

## Input

```text
Editor decision: Minor revision.

Reviewer 1:
1. Please define X in the Introduction.
2. Figure 2 legend is unclear.

Reviewer 2:
1. Please cite recent work on Y.

Author notes:
- X means cross-domain calibration.
- We revised the Introduction definition.
- We clarified the Figure 2 legend.
- We know one relevant citation but have not provided DOI or full bibliographic details yet.
```

## Expected behavior

- Assign stable IDs: `R1.1`, `R1.2`, `R2.1`.
- Classify `R1.1` and `R1.2` as minor editorial / presentation comments.
- Classify `R2.1` as citation / positioning with missing citation metadata.
- Draft concise English responses for `R1.1` and `R1.2`.
- Mark `R2.1` as `ADD_CITATION` with `AUTHOR_INPUT_NEEDED` until the citation is verified.
- Use section names when line numbers are absent.

## Forbidden behavior

- Do not invent a citation, DOI, journal, year, or title for work on Y.
- Do not claim exact line numbers.
- Do not answer any comment only with thanks.
- Do not merge the two Reviewer 1 comments into one untraceable response.

## Pass/fail checklist

- [ ] Every reviewer comment receives an ID.
- [ ] Every ID appears in the tracker and the draft letter.
- [ ] Citation metadata is requested or placeholder-flagged.
- [ ] Responses are concise and non-defensive.
- [ ] No fabricated line numbers or citation details appear.

# Test: mutually blind reviewer responses

## Input

```text
Editor decision: Major revision.

Reviewer 1:
1. Please add an external validation analysis.
2. Please clarify the replicate definition.

Reviewer 2:
1. The replicate definition is unclear.
2. The Discussion should state the limitations of external validation.

Author notes:
- External validation was completed and is reported in Results subsection 3.4.
- The replicate definition was added to Methods subsection 2.2.
- The Discussion now states the validation limitation.
```

## Expected behavior

- Build an internal/editor master tracker containing `R1.1`, `R1.2`, `R2.1`, and `R2.2`.
- Mark the master tracker as not reviewer-facing.
- Produce one standalone response for Reviewer 1 and another for Reviewer 2.
- Use neutral local labels such as `Comment 1` and `Comment 2` in each reviewer-facing file.
- Answer the replicate-definition concern fully in both files.
- Keep manuscript locations and scientific claims consistent across both files.

## Forbidden behavior

- Do not include `R2.*` IDs or Reviewer 2 comments in the Reviewer 1 file.
- Do not include `R1.*` IDs or Reviewer 1 comments in the Reviewer 2 file.
- Do not write "as the other reviewer noted" or "see our response to Reviewer 1".
- Do not disclose another reviewer's recommendation or confidential remarks.
- Do not send the internal/editor master tracker as a reviewer-facing response.

## Pass/fail checklist

- [ ] The master contains all four internal IDs and is clearly restricted to author/editor use.
- [ ] Reviewer 1 receives only Reviewer 1 comments and complete responses.
- [ ] Reviewer 2 receives only Reviewer 2 comments and complete responses.
- [ ] The repeated concern is answered independently in both files.
- [ ] No cross-reviewer phrase, ID, comment, recommendation, or response appears.
- [ ] Both reviewer-specific files describe the same manuscript changes consistently.

# nature-response test rubric

Use this rubric to manually evaluate `nature-response` outputs against the Markdown fixtures.

## Decision routing

Pass when:

- The decision type is extracted from an explicit editor letter or user statement.
- When it remains unclear, the skill asks whether this is Major Revision or Minor Revision before drafting strategy or response prose.
- Major Revision receives an evidence-first, potentially structural work plan.
- Minor Revision receives a bounded correction plan without downgrading any genuinely major or blocking concern.

Fail when:

- The skill guesses the decision type from reviewer tone, comment count, or apparent workload.
- It drafts the same undifferentiated strategy for Major and Minor Revision.
- It treats the Minor Revision label as permission to minimize an evidence, statistics, ethics, or integrity concern.

## Completeness

Pass when:

- Every reviewer comment receives a stable ID.
- Every master ID maps to the correct reviewer-specific response and local comment number.
- Repeated concerns are answered fully in every relevant reviewer-specific file rather than cross-referenced across reviewers.
- Ambiguous reviewer boundaries are flagged.

Fail when:

- A comment is skipped.
- Two concerns are merged without traceability.
- A major concern receives only a polite acknowledgement.

## Reviewer isolation

Pass when:

- The internal/editor master is clearly marked as not reviewer-facing.
- Each reviewer-facing file contains only one reviewer's comments and corresponding responses.
- Repeated concerns receive a complete standalone answer in each relevant file.
- Conflicting requests are coordinated only in the master and explained independently to each reviewer.
- All reviewer-specific files remain consistent with the same manuscript revision.

Fail when:

- A reviewer-facing response mentions another reviewer, another reviewer ID, or another recommendation.
- The response says "see our response to Reviewer 2" or uses an equivalent cross-reviewer reference.
- One reviewer is told that another reviewer requested an incompatible change.
- The master tracker is presented as if it were safe to send to every reviewer.

## Traceability

Pass when:

- Every claimed manuscript change has a section, page, line, figure, table, supplement, or explicit placeholder.
- New analyses, experiments, figures, citations, and limitations are mapped to action labels.
- Missing locations are flagged rather than invented.

Fail when:

- The response claims a change without location or evidence.
- The response invents line numbers, figure panels, supplementary items, or citation metadata.

## Factuality

Pass when:

- Missing evidence is marked `AUTHOR_INPUT_NEEDED`.
- Quantitative details are used only when supplied by the author.
- Reviewer wording is preserved unless the user asks for anonymization or summarization.

Fail when:

- The response invents data, p-values, confidence intervals, sample sizes, accession details, reviewer identities, or editor instructions.
- The response overstates unsupported causal or clinical claims.

## Tone

Pass when:

- The response is cooperative, concise, and evidence-forward.
- Disagreement is respectful and scientifically justified.
- Reviewer misunderstanding is framed as manuscript clarification when appropriate.
- A reviewer who missed existing material receives a direct answer, a clearer manuscript presentation, and a final location or visible placeholder.

Fail when:

- The response accuses the reviewer of error, incompetence, or misunderstanding.
- The response says "we already stated this", "as clearly described in the manuscript", or otherwise implies that the reviewer failed to read carefully.
- The response is excessively apologetic, defensive, or repetitive.
- The response uses time, money, or convenience as the primary reason for not doing requested work.

## Actionability

Pass when:

- The author can see what to change in the manuscript.
- Missing information is listed as concrete author questions.
- Blocking or high-risk issues are visible before the draft letter.
- If manuscript text is edited, changes are shown in red on a backed-up/copy version of the original manuscript.
- If revised manuscript text is pasted after a response, that excerpt is italic.
- LaTeX or print-oriented output uses one separate response file per mutually blind reviewer unless explicit journal instructions require a combined file.
- Every tracker row distinguishes proposed action from work status.
- Required input, expected output, and finalization-blocking state are explicit.
- `VERIFIED_DONE` rows identify the supplied artifact used for verification.

Fail when:

- The output only produces prose and no action checklist.
- The author cannot identify what evidence is still needed.
- The output overwrites the clean manuscript without a marked backup/copy.
- The response letter pastes revised manuscript text as plain non-italic body text.
- Multiple mutually blind reviewer reports are combined in one outward-facing LaTeX or print file without an explicit journal requirement.
- An author-reported but uninspected change is labelled `VERIFIED_DONE`.
- Package readiness is `ready_to_submit` while a blocking, unverified, or `TODO_*` item remains.

## Nature-fit

Pass when:

- The output is organized as editor-readable point-by-point response material.
- All referee criticisms are seriously addressed, justified, or flagged.
- The response letter could be audited if it became part of transparent peer review.

Fail when:

- The output reads like generic language polishing.
- The response hides limitations or makes compliance appear stronger than the evidence provided.

# Task-status tracking fixture

## Synthetic input

Reviewer 1 requests an external validation analysis and clearer Methods text. The author says, "The Methods are fixed," but supplies only the original manuscript. No validation result is available. A revised Methods paragraph is not supplied.

## Expected behavior

- Assign stable IDs to the validation and Methods items.
- Keep response action, work status, and package readiness separate.
- Mark the validation item `TODO_ANALYSIS`, name the required result inputs, and identify an expected validation output.
- Mark the reported Methods change `REPORTED_DONE_UNVERIFIED`, request the revised passage or location, and identify revised Methods text as the expected output.
- Mark both items as blocking finalization when they are necessary for a credible response.
- Set package readiness to `needs_author_input` or `blocked` according to the centrality of the validation request; never use `ready_to_submit`.

## Forbidden behavior

- Mark either item `VERIFIED_DONE`.
- State that the revised manuscript now contains the Methods clarification.
- Invent validation performance, sample size, line numbers, or a revised passage.
- Collapse `ACCEPT_ANALYSIS` and `TODO_ANALYSIS` into a single ambiguous status.

from __future__ import annotations

import importlib.util
import sys
import tempfile
import unittest
from pathlib import Path


SCRIPT = Path(__file__).parents[1] / "scripts" / "check_package_consistency.py"
SPEC = importlib.util.spec_from_file_location("check_package_consistency", SCRIPT)
assert SPEC and SPEC.loader
CHECKER = importlib.util.module_from_spec(SPEC)
sys.modules[SPEC.name] = CHECKER
SPEC.loader.exec_module(CHECKER)


MANUSCRIPT_TEXT = r"""
\section{Methods}
The calibration procedure uses an independent validation split and reports the
selected threshold before evaluation on the held-out test set.
"""

RESPONSE_TEXT = r"""
\ReviewerComment{Please clarify how model calibration was performed.}
\AuthorResponse{We have clarified the calibration procedure in the Methods.}
\RevisedExcerpt{The calibration procedure uses an independent validation split and reports the
selected threshold before evaluation on the held-out test set.}
"""


class PackageConsistencyTests(unittest.TestCase):
    def write(self, root: Path, name: str, content: str) -> Path:
        path = root / name
        path.write_text(content, encoding="utf-8")
        return path

    def test_consistent_package_passes(self) -> None:
        with tempfile.TemporaryDirectory() as directory:
            root = Path(directory)
            manuscript = self.write(root, "main.tex", MANUSCRIPT_TEXT)
            response = self.write(root, "response.tex", RESPONSE_TEXT)
            clean = self.write(root, "clean.tex", MANUSCRIPT_TEXT)
            marked = self.write(
                root,
                "marked.tex",
                MANUSCRIPT_TEXT.replace(
                    "The calibration procedure",
                    r"\revised{The calibration procedure}",
                ),
            )

            findings = CHECKER.run_checks(manuscript, response, clean, marked)

        self.assertEqual([], findings)

    def test_quote_mismatch_is_reported(self) -> None:
        with tempfile.TemporaryDirectory() as directory:
            root = Path(directory)
            manuscript = self.write(root, "main.tex", MANUSCRIPT_TEXT)
            response = self.write(
                root,
                "response.tex",
                RESPONSE_TEXT.replace("independent validation split", "five-fold cross-validation"),
            )

            findings = CHECKER.run_checks(manuscript, response)

        self.assertIn("QUOTE_NOT_IN_MANUSCRIPT", {item.code for item in findings})

    def test_comment_response_count_mismatch_is_reported(self) -> None:
        with tempfile.TemporaryDirectory() as directory:
            root = Path(directory)
            manuscript = self.write(root, "main.tex", MANUSCRIPT_TEXT)
            response = self.write(
                root,
                "response.tex",
                RESPONSE_TEXT + r"\ReviewerComment{Please report the software version.}",
            )

            findings = CHECKER.run_checks(manuscript, response)

        self.assertIn("COMMENT_RESPONSE_COUNT_MISMATCH", {item.code for item in findings})

    def test_clean_marked_content_drift_is_reported(self) -> None:
        with tempfile.TemporaryDirectory() as directory:
            root = Path(directory)
            manuscript = self.write(root, "main.tex", MANUSCRIPT_TEXT)
            response = self.write(root, "response.tex", RESPONSE_TEXT)
            clean = self.write(root, "clean.tex", MANUSCRIPT_TEXT)
            marked = self.write(
                root,
                "marked.tex",
                MANUSCRIPT_TEXT.replace("held-out test set", "training set"),
            )

            findings = CHECKER.run_checks(manuscript, response, clean, marked)

        self.assertIn("CLEAN_MARKED_TEXT_MISMATCH", {item.code for item in findings})

    def test_multifile_manuscript_inputs_are_expanded(self) -> None:
        with tempfile.TemporaryDirectory() as directory:
            root = Path(directory)
            manuscript = self.write(root, "main.tex", r"\input{methods}")
            self.write(root, "methods.tex", MANUSCRIPT_TEXT)
            response = self.write(root, "response.tex", RESPONSE_TEXT)

            findings = CHECKER.run_checks(manuscript, response)

        self.assertEqual([], findings)

    def test_declared_cross_reference_substitution_passes(self) -> None:
        with tempfile.TemporaryDirectory() as directory:
            root = Path(directory)
            manuscript = self.write(
                root,
                "main.tex",
                r"The primary measurements are summarized in Table \ref{tab:main} for independent evaluation.",
            )
            response = self.write(
                root,
                "response.tex",
                r"""
\ReviewerComment{Please identify the relevant table.}
\AuthorResponse{We now identify the relevant table.}
\RevisedExcerpt{The primary measurements are summarized in Table 1 for independent evaluation.}
""",
            )

            findings = CHECKER.run_checks(
                manuscript,
                response,
                substitutions=[(r"Table \ref{tab:main}", "Table 1")],
            )

        self.assertEqual([], findings)

    def test_deleted_text_is_removed_for_marked_comparison(self) -> None:
        with tempfile.TemporaryDirectory() as directory:
            root = Path(directory)
            clean_text = "The model uses cohort A and cohort C for evaluation."
            manuscript = self.write(root, "main.tex", clean_text)
            response = self.write(
                root,
                "response.tex",
                r"\ReviewerComment{Please clarify the cohort definition.}"
                r"\AuthorResponse{We removed the obsolete cohort.}",
            )
            clean = self.write(root, "clean.tex", clean_text)
            marked = self.write(
                root,
                "marked.tex",
                r"The model uses cohort A and \deletedtext{cohort B and }cohort C for evaluation.",
            )

            findings = CHECKER.run_checks(manuscript, response, clean, marked)

        self.assertEqual([], findings)


if __name__ == "__main__":
    unittest.main()

from pathlib import Path


ROOT = Path(__file__).parents[1]


def read(relative: str) -> str:
    return (ROOT / relative).read_text(encoding="utf-8")


def test_decision_type_gate_is_part_of_the_runtime_contract() -> None:
    router = read("SKILL.md")
    workflow = read("static/core/workflow.md")

    assert "Major Revision" in router and "Minor Revision" in router
    assert "pause and ask the user" in workflow
    assert "do not draft a generic response" in workflow


def test_reviewer_isolation_is_required_in_core_and_qa() -> None:
    stance = read("static/core/stance.md")
    qa = read("references/qa-checklist.md")

    assert "mutually blind by default" in stance
    assert "must not reveal another reviewer's" in stance
    assert "Each reviewer-facing file contains only one reviewer's comments" in qa
    assert "complete standalone answer" in qa


def test_missed_existing_text_is_treated_as_a_clarity_problem() -> None:
    stance = read("static/core/stance.md")
    qa = read("references/qa-checklist.md")

    assert "not sufficiently visible or clear" in stance
    assert 'No response says "we already stated this"' in qa


def test_punctuation_guard_is_present_in_core_and_qa() -> None:
    stance = read("static/core/stance.md")
    qa = read("references/qa-checklist.md")

    assert "Avoid em dashes, en dashes, and colons" in stance
    assert "No avoidable em dash, en dash, or colon" in qa

# Test: unclear revision decision type

## Input

```text
Reviewer 1:
1. Please clarify the validation design.

Reviewer 2:
1. The Discussion should better explain the study limitations.

请帮我准备逐点回复和手稿修改计划。
```

## Expected behavior

- Recognize that this is normal revision-response work but the editorial decision type is missing.
- Ask one concise question before drafting: whether this is `Major Revision` or `Minor Revision`.
- If the user writes Chinese, ask: `这是 Major Revision（大修）还是 Minor Revision（小修）？如果决定信没有明确写，请把决定信发给我，我帮你判断。`
- Pause substantive response strategy and response-letter drafting until the user answers or supplies the decision letter.

## Forbidden behavior

- Do not infer Major Revision from the validation comment.
- Do not infer Minor Revision from the small number of visible comments.
- Do not produce a generic point-by-point response that treats both decision types as equivalent.
- Do not ask again if a subsequently supplied editor letter explicitly states the decision type.

## Pass/fail checklist

- [ ] The decision-type question is asked before substantive drafting.
- [ ] No revision type is guessed.
- [ ] No Major/Minor strategy is selected prematurely.
- [ ] The user is invited to provide the decision letter if its wording is unclear.