Nature Response

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 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. 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 ten-step 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 / 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.

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 ten-step workflow in core/workflow.md: identify mode and decision type, extract editor instructions (IDs E.1) then reviewer comments (R1.1, R2.1), classify each item, build a strategy summary, draft point-by-point responses from the preserved comments, map every claimed change to a manuscript location or an explicit placeholder, flag missing author input, run QA, and return the package with a readiness state.

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/ are deep references, 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, and references/qa-checklist.md before finalizing.

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.

Example: conflicting reviewers

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

Input

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 in the 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.

Response style

We appreciate the reviewer's suggestion to sharpen the abstract. However, because the study is
observational, we agree with the editor's instruction to clarify the central claim without
overstating causality. 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.

The response must not promise both stronger causal language and softened causal language.

Example: major revision with missing evidence

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

Input

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

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

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

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

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

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

| ID | Reviewer concern | Type | Severity | Proposed action | Readiness | Missing author input |
|---|---|---|---|---|---|---|
| R1.1 | Define cross-domain calibration | Editorial / presentation | Minor | ACCEPT_TEXT | draft_with_placeholders | Line or section location |
| R1.2 | Explain Figure 2 colour scale | Editorial / figure | Minor | ACCEPT_FIGURE | draft_with_placeholders | Line or legend location |

Response style

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.

nature-response skill

A reviewer-response skill for drafting, auditing, and revising point-by-point response letters for Nature-family and high-impact journal manuscript revisions.

This skill is bilingual-aware. It accepts Chinese or English reviewer comments, editor letters, author notes, and draft rebuttals, then prepares an English response package with Chinese author confirmation notes when useful.

What it does

• splits reviewer comments into stable IDs such as R1.1, R1.2, and R2.1
• classifies each concern by type, severity, action, evidence need, and risk
• creates a response strategy summary before drafting prose
• routes requests into drafting, auditing, revising, triage-only, or appeal-like handling
• assigns editor instruction IDs such as E.1 before reviewer IDs when the decision letter includes editor instructions
• drafts an editor-readable point-by-point response letter
• maps each response to a manuscript action, location, or missing-information flag
• rewrites defensive or vague author notes into professional response language
• handles difficult cases such as out-of-scope experiments, factual reviewer errors, conflicting reviewers, statistical critiques, and compliance concerns
• flags missing experiments, analyses, line numbers, citations, figure panels, and manuscript changes instead of inventing them

When to use

• preparing a Nature, Nature Portfolio, Springer Nature, or similar high-impact journal revision
• responding to major or minor revision comments
• turning reviewer comments into a manuscript change checklist
• auditing a draft rebuttal for missing responses, tone problems, or unsupported claims
• converting Chinese author notes into submission-ready English point-by-point replies
• deciding how to respectfully disagree with a reviewer or explain a scope boundary

What it returns

Unless the user asks for another format, the skill returns:

1. response strategy summary 2. comment-response tracker 3. draft point-by-point response letter 4. manuscript change checklist 5. missing information / risk flags 6. Chinese confirmation notes when the user writes in Chinese

Core rules

• Preserve reviewer comments faithfully before responding.
• Answer every concern, cross-reference it, or mark it unresolved.
• Map every response to a concrete action such as ACCEPT_TEXT, ACCEPT_ANALYSIS, SOFTEN_CLAIM, DISAGREE, or AUTHOR_INPUT_NEEDED.
• Do not invent experiments, analyses, citations, line numbers, figure panels, supplementary items, reviewer identities, editor instructions, or manuscript changes.
• Use cooperative, evidence-forward, non-defensive language.
• Treat the response letter as an editor-facing verification document, not a politeness exercise.

Source hierarchy

• Target journal instructions and decision-letter requirements.
• Nature / Nature Portfolio / Springer Nature revision and peer-review process guidance.
• Springer Nature editorial advice on rebuttal letters.
• Local manuscript facts supplied by the author.

The source basis is summarized in references/source-basis.md with URLs, rule summaries, and source-type labels.

File structure

The skill uses a router/static-dynamic split (like the other nature-* skills): a short SKILL.md router plus a manifest.yaml. nature-response is a linear workflow with no content axis, so the split is core (always loaded) plus on-demand references.

nature-response/
├── README.md
├── SKILL.md                     # short router
├── manifest.yaml                # always_load core + on-demand references (no axis)
├── static/
│   └── core/                    # always loaded
│       ├── stance.md            # purpose, default stance, red lines, source hierarchy
│       └── workflow.md          # accepted inputs, 10-step workflow, output format
├── references/
│   ├── source-basis.md
│   ├── response-structure.md
│   ├── comment-taxonomy.md
│   ├── action-mapping.md
│   ├── tone-and-stance.md
│   ├── chinese-author-alignment.md
│   ├── difficult-cases.md
│   ├── intake-and-routing.md
│   └── qa-checklist.md
├── tests/
    ├── conflicting-reviewers.md
    ├── defensive-draft-audit.md
    ├── evaluation-summary.md
    ├── minor-revision.md
    ├── major-revision-missing-evidence.md
    ├── impossible-experiment.md
    └── rubric.md
└── examples/
    ├── conflicting-reviewers.md
    ├── major-revision-with-missing-evidence.md
    └── minor-revision.md

Status

Beta. The behavior is defined by synthetic Markdown fixtures and examples. The skill should remain below Stable until it has been validated on real anonymized revision packages with author permission.

Action mapping

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

Action labels

Internal tracker fields

Use this shape internally when organizing a response:

comment_id: R1.3
reviewer: Reviewer 1
severity: major
category: methodological
action: ACCEPT_ANALYSIS
author_input_needed: true
readiness: draft_with_placeholders
risk_level: high
manuscript_location: Methods; Results; Supplementary Fig. S2

Readiness state

Risk level

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 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 is factually wrong, usually combine CLARIFY_EXISTING with a small text clarification.
• 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 confirmation section

Use concise Chinese action notes:

中文核对
- 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:

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

Response stance:

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:

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

Response stance:

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

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

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:

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. Cite the existing manuscript location or supplied evidence. 3. Clarify wording if the manuscript invited confusion. 4. Consider a small revision even when the reviewer is wrong.

Template:

We appreciate the reviewer raising this point. The relevant data are provided in [location],
where we show [supplied evidence]. We have revised [location] to make this clearer.

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. If necessary, explain the balancing choice in the relevant responses.

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:

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

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.

Task modes

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:

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:

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.

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

Usually proceed with placeholders and risk flags. Ask concise questions only when:

• 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:

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.

QA checklist

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 cross-referenced rather than ignored.
• No major concern is answered only with thanks.
• Editor-specific instructions are addressed before reviewer comments when supplied.

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.

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 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.

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.

Readiness gate

Use these labels consistently:

• ready_to_submit: all comments are answered with supplied actions and traceable locations.
• 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

Use this file when drafting or auditing the output shape of a reviewer response package.

Default package

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

1. Response strategy summary. 2. Comment-response tracker. 3. Draft point-by-point response letter. 4. Manuscript change checklist. 5. Missing information / risk flags. 6. Chinese confirmation notes when the user writes in Chinese.

Response strategy summary

Keep this short and editor-readable:

Response strategy summary
- Decision type: Major revision
- Task mode: draft
- Package readiness: draft_with_placeholders
- Overall posture: Cooperative, evidence-forward, non-defensive
- Major risks: missing validation results; unclear replicate definition
- Suggested ordering: address editor first, then Reviewer 1 and Reviewer 2 in full

Decision types:

• minor revision
• major revision
• revise-and-resubmit
• transfer after review
• appeal-like case routed outside the default workflow
• unclear when the decision type is not supplied

Task modes:

• draft
• audit
• revise
• triage-only
• 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.

Comment-response tracker

Use a compact table:

| ID | Reviewer concern | Type | Severity | Proposed action | Readiness | Missing author input |
|---|---|---|---|---|---|---|
| R1.1 | Missing validation cohort | Evidence / validation | Major | ACCEPT_ANALYSIS | needs_author_input | Need result summary and manuscript location |

Keep reviewer concern text short in the tracker. Preserve the full wording in the letter when available. Use E.1, E.2, etc. for editor instructions and list them before reviewer comments.

Point-by-point letter anatomy

Use this default structure:

Dear Editor and Reviewers,

We thank the editor and reviewers for their careful evaluation of our manuscript.
We have revised the manuscript to address the concerns raised and provide a point-by-point response below.

## Response to Reviewer 1

**Reviewer comment R1.1**
[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 needed: The remaining limitation is now stated in [location].]

Manuscript change checklist

List manuscript actions, not polite intentions:

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.

Missing information / risk flags

Use specific requests:

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.

Cover letter boundary

Some journals ask for a revised manuscript, response to reviewers, and cover letter. This MVP does not generate cover letters. If the user asks for one, state that it is adjacent to the response package and should be handled as a separate task.

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

Implementation implications

• Point-by-point response is the default structure for revision cases.
• Every referee criticism must be answered, justified, cross-referenced, or flagged as unresolved.
• A cover letter can be mentioned as adjacent revision-package material, but this skill does not draft it by default.
• 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

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:

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:

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.

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

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:

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. Treat the misunderstanding as a presentation signal:

We agree that the original text did not make this distinction sufficiently clear. We have revised
the [section] to clarify that [specific distinction].

Out-of-scope pattern

When declining a requested experiment or analysis:

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.

Default stance and red lines

Use this skill to convert editor decision letters, reviewer comments, author notes, or draft rebuttals into an auditable point-by-point response package for manuscript revisions.

The response letter is an editor-facing verification document. 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.

Default stance

• Preserve each reviewer comment faithfully before responding.
• Every reviewer concern must be answered, cross-referenced, or explicitly marked as unresolved.
• Map every response to manuscript evidence, a revision location, a justified disagreement, or AUTHOR_INPUT_NEEDED.
• 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.
• 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.
• Treat rebuttal letters as potentially public review artifacts; write with professional tone and traceability.

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 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 generate an appeal letter as the default path. Route appeal-like cases separately.
• Do not generate a cover letter in the MVP. Mention it only as adjacent revision-package material when relevant.

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. 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: 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.

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

Workflow

1. Identify task mode and input readiness: draft, audit, revise, triage-only, or appeal-like. 2. Identify decision type: minor revision, major revision, revise-and-resubmit, transfer after review, or unclear. 3. 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. 4. Classify each item by category, severity, action label, missing input, readiness state, and risk. 5. Create a response strategy summary before drafting prose. 6. Draft responses using preserved reviewer comments unless the mode is triage-only or appeal-like. 7. Map each claimed change to manuscript location, figure, table, supplement, citation, or explicit placeholder. 8. Flag missing author input rather than fabricating details. 9. Run QA for completeness, traceability, factuality, tone, and unresolved risk. 10. Return the response package with package readiness: ready_to_submit, draft_with_placeholders, needs_author_input, or blocked.

Output format

Unless the user asks for another format, return:

Response strategy summary
- Decision type:
- Overall posture:
- Major risks:
- Suggested ordering:

Comment-response tracker
| ID | Reviewer concern | Type | Severity | Proposed action | Missing author input |
|---|---|---|---|---|---|

Draft point-by-point response letter
[editor-readable English response]

Manuscript change checklist
- [specific manuscript changes or placeholders]

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

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

Test: conflicting reviewers

Input

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.
• 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.
• 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.

Pass/fail checklist

• [ ] E.1 appears in the tracker or strategy summary.
• [ ] The conflict is surfaced explicitly.
• [ ] The chosen response is consistent with the observational design.
• [ ] R1.1 and R2.1 are both answered.
• [ ] No incompatible manuscript-change promises appear.

Test: defensive draft audit

Input

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.
• 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 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.
• [ ] Each reviewer comment receives its own ID.
• [ ] Revised response includes manuscript-clarity framing.
• [ ] 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 minor revision, major revision with missing evidence,

impossible experiment, defensive draft audit, and conflicting reviewers.

• 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

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

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

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

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.

nature-response test rubric

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

Completeness

Pass when:

• Every reviewer comment receives a stable ID.
• Every ID appears in the tracker and response letter.
• Repeated concerns are cross-referenced rather than ignored.
• 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.

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.

Fail when:

• The response accuses the reviewer of error, incompetence, or misunderstanding.
• 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.

Fail when:

• The output only produces prose and no action checklist.
• The author cannot identify what evidence is still needed.

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.