first commit

This commit is contained in:
2026-06-11 03:33:14 +08:00
commit 5f555bf342
599 changed files with 142347 additions and 0 deletions

View File

@@ -0,0 +1,94 @@
# `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
```text
nature-response/
├── README.md
├── SKILL.md
├── 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.

View File

@@ -0,0 +1,127 @@
---
name: nature-response
description: >-
Draft, audit, or revise point-by-point reviewer response letters for Nature-family
manuscript revisions. Use when the user provides reviewer comments, editor decision
letters, revision notes, response drafts, or asks how to respond to major/minor
revision requests, rebuttal letters, response to reviewers, peer-review reports,
审稿意见回复, 逐点回复, 修回信, 大修回复, 小修回复, or 如何回复 reviewer.
version: 0.1.0
status: Beta
---
# Nature Reviewer Response Skill
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.
## 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:
```text
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]
```
## 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.
## Related files
| File | Open when |
|---|---|
| [references/intake-and-routing.md](references/intake-and-routing.md) | Before drafting, to identify task mode, minimum inputs, editor IDs, readiness state, and clarifying-question need |
| [references/source-basis.md](references/source-basis.md) | You need source hierarchy, rule provenance, or policy-vs-advice boundaries |
| [references/response-structure.md](references/response-structure.md) | You need the response package format or point-by-point letter anatomy |
| [references/comment-taxonomy.md](references/comment-taxonomy.md) | You need to classify reviewer comments by category and severity |
| [references/action-mapping.md](references/action-mapping.md) | You need action labels, tracker fields, and missing-input states |
| [references/tone-and-stance.md](references/tone-and-stance.md) | You need recommended language, forbidden phrasing, or disagreement tone |
| [references/chinese-author-alignment.md](references/chinese-author-alignment.md) | The user writes in Chinese or provides Chinese author notes |
| [references/difficult-cases.md](references/difficult-cases.md) | The comments involve impossible experiments, factual errors, conflicting reviewers, citations, statistics, compliance, transfer, or appeal-like cases |
| [references/qa-checklist.md](references/qa-checklist.md) | Before finalizing an output or auditing a draft response |
## 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.

View File

@@ -0,0 +1,42 @@
# 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 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
```text
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.

View File

@@ -0,0 +1,52 @@
# 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.
```

View File

@@ -0,0 +1,51 @@
# 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 | 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
```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.

View File

@@ -0,0 +1,63 @@
# Action mapping
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
author_input_needed: true
readiness: draft_with_placeholders
risk_level: high
manuscript_location: Methods; Results; Supplementary Fig. S2
```
## Readiness state
| State | Meaning |
|---|---|
| `ready_to_submit` | Enough facts are supplied to draft final text with traceable manuscript location |
| `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 |
## 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 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.

View File

@@ -0,0 +1,75 @@
# 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].
```

View File

@@ -0,0 +1,95 @@
# 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.

View File

@@ -0,0 +1,131 @@
# 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:
```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. 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:
```text
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:
```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.
```

View File

@@ -0,0 +1,107 @@
# 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
| 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 | Full response package 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 |
| `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.
## 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:
```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`.

View File

@@ -0,0 +1,64 @@
# 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.

View File

@@ -0,0 +1,114 @@
# 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:
```text
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:
```markdown
| 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:
```markdown
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:
```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.
```
## 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.
```
## 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.

View File

@@ -0,0 +1,33 @@
# 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` handles the reviewer response; cover-letter generation is out of MVP scope. |
| 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, 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.

View File

@@ -0,0 +1,95 @@
# 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:
```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.
```
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:
```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. Treat the misunderstanding as a presentation signal:
```text
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:
```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.

View File

@@ -0,0 +1,49 @@
# 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.
- 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.

View File

@@ -0,0 +1,47 @@
# 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.
- 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.

View File

@@ -0,0 +1,43 @@
# 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
| Fixture | Coverage | Key failure prevented |
|---|---|---|
| `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, vague compliance | accusatory reviewer language |
| `conflicting-reviewers.md` | editor priority and incompatible reviewer requests | contradictory manuscript promises |
## 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.

View File

@@ -0,0 +1,42 @@
# 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.

View File

@@ -0,0 +1,40 @@
# 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.

View File

@@ -0,0 +1,44 @@
# 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.

View File

@@ -0,0 +1,84 @@
# 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.