Revise

Revision Skill -- Response to Peer Reviewers

Purpose

Parse reviewer decision letters, classify each comment by type, generate a formal Response to Reviewers document, track required manuscript changes, and coordinate with /analyze-stats or /make-figures when new analyses or visuals are needed.

---

Activation

When the user provides reviewer comments (pasted text, PDF, or file path), or requests revision of a manuscript, this skill activates. Before proceeding, confirm:

1. The reviewer decision letter (pasted text or file path) 2. The current manuscript file (paper/main.tex or paper/main.qmd) 3. The revision round number (default: R1) 4. The journal name (affects cover letter format)

---

Reference Files

• Response-letter voice gallery: ${CLAUDE_SKILL_DIR}/references/r2r_voice.md -- before/after examples, three response skeletons (accept / partial-accept / polite-rebuttal), and a meta-phrase-to-natural conversion table. Read it before drafting the Response to Reviewers document.

---

Step 1: Parse and Number All Comments

Read the full decision letter. Extract every discrete comment from every reviewer and the editor.

Numbering Convention

E-1, E-2, ...       <- Editor comments
R1-1, R1-2, ...     <- Reviewer 1 comments
R2-1, R2-2, ...     <- Reviewer 2 comments
R3-1, R3-2, ...     <- Reviewer 3 (if present)

If a reviewer groups multiple requests in one paragraph, split them into sub-items: R1-3a, R1-3b, R1-3c

Classification

Output a classified comment list before generating responses:

E-1   [MIN]  Request to shorten abstract
R1-1  [MAJ]  Requires subgroup analysis by scanner type
R1-2  [MIN]  Clarify exclusion criteria rationale
R1-3  [REB]  Claims our sample size is underpowered (we disagree)
R2-1  [MAJ]  Requires additional figure showing calibration curve
R2-2  [MIN]  Add reference to [Author Year]

Gate: Present the classified comment list to the user. Confirm classifications (especially REBUTTAL vs MAJOR) before generating responses. A misclassified REBUTTAL generates a response that argues with a valid reviewer point.

---

Step 2: Triage -- Flag External Actions Needed

Before writing responses, identify which comments require external action:

Comments requiring /analyze-stats: Flag any MAJOR comment that requires new statistical analysis, re-run of existing analysis, additional metric (calibration, NRI, ICC), or sample size recalculation. When the source is a /self-review finding, any issue carrying requires_reanalysis: true (power/MDE re-simulation under the full model, first-visit / one-record-per-subject dedup, an extended- or reduced-adjustment over-adjustment sensitivity, optimism correction of calibration) is automatically a /analyze-stats routing item — it cannot be answered by a prose edit, so it must produce a committed script + CSV whose numbers are then fed back here.

Comments requiring /make-figures: Flag any MAJOR comment that requires a new figure or revised figure (calibration plot, subgroup forest plot, Bland-Altman, new panel).

Output: "The following comments require statistical analysis before responses can be finalized: R1-1, R2-3. Run /analyze-stats with these tasks, then return to /revise."

---

Step 2.5: Revision Numerical Lineage Check (MANDATORY)

Revision-time is the highest-risk moment for numerical hallucinations. A new analysis script written to satisfy a reviewer — typically a comparative arm, a subgroup, or a sensitivity check — frequently hand-enters values copied by eye from the original paper's tables, bypassing the locked extraction CSV. The resulting numbers then flow into the response letter, the revised manuscript, and regenerated figures, and they can be internally consistent everywhere while still being wrong at the source.

Precedent failure pattern — treat as a lived failure, not hypothetical:

An R1 revision introduced a new comparative-arm analysis script to answer a reviewer

request. The Fisher exact matrix was hand-typed from the primary source Table, with an

adjacent severity-grade column misread as the event count. The script, the revised

manuscript, and an accompanying Table all converged on the same direction-reversed

numbers relative to what the primary source actually reported.

Non-negotiable actions when Step 2 flags any `/analyze-stats` re-run:

1. Tag every new numerical claim with `[VERIFY-CSV]` as it is written into the revised manuscript, response letter, or new table. The tag is a tripwire — it only comes off at Step 7 (Final Verification) after explicit CSV + primary-source back-check.

2. New analysis scripts must read from the locked extraction CSV. Hand-typed matrix(), c(...), or data.frame(...) numerical inputs are PROHIBITED when a CSV row exists. If hand entry is truly unavoidable (e.g., comparative-arm subset not present in the CSV), the line MUST carry a comment citing the CSV coordinate AND the primary-source Table/Figure:

   # source: data_extraction_final.csv row <N> (<first-author> <year>, <arm> only),
   #         verified against <primary source> Table <X>, page <P>
   fisher.test(matrix(c(0, 45, 1, 55), nrow = 2, byrow = FALSE))

3. Comparative / arm-specific values must enter `extraction_consensus_log.md` as separate rows before the analysis script references them. Do not let a new script invent values that never passed through the dual-extraction consensus layer.

4. Revision-time numerical audit table — maintain this inside the response document draft and copy into the final change log:

5. Gate before Step 3 — do not generate response prose for a MAJOR comment whose new numbers have not yet cleared this check. Prose written around un-audited numbers is very hard to unwind cleanly after a mismatch is found.

Why this matters for reviewer politics: a numerical reversal caught by the reviewer in R2 is far more damaging than the same error caught internally in R1 — it implies extraction integrity problems to the editor and licenses deeper scrutiny of the rest of the data. Treat Step 2.5 as a reputation-preservation gate, not just a QC step.

---

Step 3: Generate Response to Reviewers Document

Output location: revision/R[N]/response_to_reviewers_R[N].md

Document Header

Response to Reviewers

Manuscript ID: [JOURNAL-XXXXX]
Manuscript Title: [Full title]
Authors: [Last name of first author] et al.
Revision Round: [R1 / R2 / R3]
Date: [YYYY-MM-DD]

We thank the Editor and reviewers for their careful reading of our manuscript
and their constructive comments. We have revised the manuscript accordingly
and provide a point-by-point response below. All changes are shown in the
revised manuscript with tracked changes (or highlighted in yellow).

Per-Comment Response Block

---

**Comment R[X]-[Y]** [MAJ/MIN/REB]

*Reviewer's comment:*
> [Exact text of the comment, quoted verbatim]

**Response:**

[Response text -- format by type below]

**Manuscript change:**
- Section: [Methods / Results / Discussion / etc.]
- Page [X], Line [Y] (in the revised manuscript)
- [Quote the new or changed sentence if short]

---

Step 4: Response Formats by Comment Type

MINOR Comment

Keep concise (3-8 sentences). Acknowledge, explain the change.

We thank the reviewer for this observation. We have [describe change] in
the [section] section. The revised text now reads: "[new sentence]."

MAJOR Comment

Structured response with four parts: acknowledgment -> new analysis -> key result -> location of changes.

We thank the reviewer for this important suggestion. [State the concern.]

To address this, we [describe new analysis/experiment/rewrite].
[Key result: metric = value (95% CI, lower-upper; P = exact value)]
(All new results MUST include 95% CI and exact p-value.)

This finding [supports / strengthens / does not change] our original
conclusion because [brief interpretation].

Note: New text added to the Results section must contain only factual
findings. Interpretation belongs in the response letter text or Discussion.

We have added:
- New [Table X / Figure X / Supplementary Table X] showing [content]
- Methods revised: Page X, Lines Y-Z
- Results revised: Page X, Lines Y-Z

REBUTTAL Comment

Polite but firm. Do not capitulate without scientific justification.

We thank the reviewer for raising this point. We respectfully suggest
that [restate reviewer's claim], while we [state your position].

[Explanation with supporting evidence. Cite literature if available:
"This is consistent with [Author et al., Year; PMID XXXXXX], who
demonstrated that..."]

[If applicable: "We have added the following clarifying sentence to
[section] (Page X, Line Y): '[new sentence].'"]

We believe this issue does not warrant [the specific change requested]
because [reason]. We hope the reviewer finds this explanation satisfactory.

Voice caution: The acknowledgment lines in these templates are schematic placeholders, not literal text to paste under every comment. Repeating the same opener ("We thank the reviewer for this important suggestion.") across a dozen responses is itself an AI-tell that careful reviewers notice. Vary the openers and apply the Response-Letter Voice & AI-Tell Avoidance section below before finalizing any response.

---

5-Category Triage Strategy

Before writing individual responses, classify every comment into one of five categories. This classification determines the response template and effort level. Process Category 1 (Simple) comments first — they are the most numerous and clearing them early reduces the perceived workload.

Category 1: Simple Question (most common)

Reviewer asks for additional description, clarification, or minor data. Response: Add the requested text and point to the location. Keep the response short. Example: "Please specify the study period" → add dates, reply "Done. See page X, line Y."

Category 2: Misunderstanding

Reviewer misinterpreted the study design, population, or analysis. Response: Never say "you are wrong." Instead: "We apologize for the lack of clarity" → re-explain the intended meaning → revise the manuscript text to prevent future confusion.

Category 3: Further Discussion

Reviewer raises a contextual concern (different healthcare system, different clinical practice). Response: Acknowledge the valid perspective → explain your study context → add a brief note in Discussion if appropriate. The full explanation can stay in the response letter without bloating the manuscript.

Category 4: Additional Results

Reviewer requests new analysis (subgroup, sensitivity, additional metric). Response: Perform the analysis → add results to Supplementary (or main text if important) → describe what was done and what was found. Treat this as a constructive contribution, not an attack. Never ignore these requests — reviewer engagement is a positive signal.

Category 5: Statistical Method Challenge

Reviewer questions or requests changes to statistical methods. Response: Consult a biostatistician if unfamiliar → provide a reasoned justification for your method choice with references → if the reviewer's suggestion is valid, perform both analyses and show results are consistent. "This analysis was reviewed in consultation with our biostatistician" adds credibility.

Mapping to MAJ/MIN/REB

Use the 5-category triage to inform the MAJ/MIN/REB classification in Step 1, not replace it.

---

Handling Low-Quality Reviews

Reviewer quality varies widely. When facing comments that suggest the reviewer did not carefully read the manuscript:

1. Do not get combative. Respond with the same professionalism regardless of review quality. 2. Address every point, even trivial or off-topic ones. Skipping a comment signals disrespect to the editor. 3. For irrelevant comments: Add a clarifying sentence to Discussion or Methods, and reply: "We have added clarification in [section] to address this concern." This shows effort without conceding a scientific point. 4. For factually incorrect comments: Provide evidence (with references) politely. Frame as "We believe there may be a misunderstanding" rather than "The reviewer is wrong." 5. Remember the audience: The response letter is read by the editor, not just the reviewer. A measured, thorough response demonstrates manuscript quality even when the review does not.

---

Response-Letter Voice & AI-Tell Avoidance

A response-to-reviewers letter is a reviewer-facing scientific argument, not an internal change-log. The dominant AI-tell in machine-drafted letters is the editing-mechanism register: prose that narrates how the text was edited ("the revised Methods adds one sentence at line 88", "a grep-and-soften pass replaced six phrases", "no further manuscript change") instead of stating, in plain language, what changed and why.

Three principles when drafting (the AI-tell patterns themselves are defined once in humanize references/ai_patterns.md, patterns 22-24 — this section is the authoring guidance):

1. Write the change and the science, not the editing mechanism. Describe what changed and why, and quote the new sentence. Never narrate the diff: no version prefixes ("v2 adds..."), no "softened N phrases", no grep/verification language, no internal FIX codes, no bare "No further manuscript change" stubs. Describing a new analysis you ran ("we performed a sensitivity analysis and found X") is the science, not a tell — that is welcome. 2. No `§` symbols, no internal draft line numbers. A revised-manuscript page/line ("page 7, lines 177-178", stated once as referring to the revised manuscript) is fine; only internal draft line numbers that will not match the reviewer's view are banned. 3. Format is free. Free prose, a structured Response: / Changes made: block, an Original → Revised pair, or a left-comment/right-response table are all standard human conventions. Pick any; strip only the mechanism narration.

Reviewer-facing tone

• Vary openers. "We thank the reviewer for this point." / "We agree." / "This is an important concern." / "We have addressed this as follows." Do not repeat one acknowledgment sentence down the whole letter.
• Calibrate the stance: full agreement, partial agreement with a bounded clarification, or a polite, evidence-backed rebuttal. Match the register to the substance.
• Admit error plainly when the reviewer is right ("The reviewer is correct; we have corrected this.") — natural humility reads as human and builds editor trust.
• Quote the new manuscript text verbatim in quotation marks, then name its section — what experienced authors do, and the single strongest human signal across real letters.

Succinctness & non-defensiveness (especially R2+)

Let the point-by-point prove the work; strip the pre-emptive defence. This matters most on R2+ rounds, where over-explaining reads as anxiety rather than rigor.

• No pre-emptive hand-holding. Drop "Reviewers 2 and 3 also accepted this," "we left it unchanged because the other reviewers were satisfied," and similar cross-reviewer lobbying. Answer the comment in front of you.
• A satisfied reviewer gets one sentence. If a reviewer is content or offers only praise, "We thank the reviewer." or a single sentence is the whole response. Do not manufacture paragraphs.
• Cut defensive meta-comments. Remove "We confirm this statement is unchanged and not softened," "These passages already make the point, so no further text was added." State plainly where the matter is handled and move on.
• Fold methodology disclosure into the comment it answers. Multiplicity, a SAP deviation, or an analysis caveat goes inside the relevant response — not into a separate "Statistical note" front section. Keep the disclosure (never hide a deviation), but keep it in place.
• Split, do not bundle. When a reviewer packs several points into one paragraph, answer each as its own comment with that reviewer sentence quoted, not one block reply to the whole paragraph. Succinct means short answers, not fewer comments.

See ${CLAUDE_SKILL_DIR}/references/r2r_voice.md for the before/after gallery, response skeletons, and the meta-phrase conversion table.

Mandatory pre-submission scan

Before circulating or uploading the response letter and cover letter, run /humanize on both documents. The R2R AI-tell patterns (22-24) are defined in humanize references/ai_patterns.md; together with 13 (em dash), 16 (filler), and 19 (§) they form the response-letter scan. Also apply ~/.claude/rules/manuscript-style-classical.md (§, em-dash, heading discipline) — the same senior-reviewer red flags apply to the letter.

---

Step 5: Cover Letter to Editor

Output location: revision/R[N]/cover_letter_R[N].md

[Date]

Dear Dr. [Editor Name / "Editor-in-Chief"],

Thank you for the opportunity to revise our manuscript, "[Full title]"
(Manuscript ID: XXXX), submitted to [Journal Name]. We have carefully
reviewed the comments from the Editor and reviewers and have revised
the manuscript accordingly.

In brief, the principal changes in this revision are: [1) ..., 2) ...,
3) ...]. A point-by-point response to each comment is provided in the
accompanying Response to Reviewers document. Revised sections are
highlighted in yellow in the manuscript.

We believe the revised manuscript addresses all concerns raised in the
review and is now suitable for publication in [Journal Name].

Sincerely,

[First Author Name], MD/PhD
[Institution]
[Email]
On behalf of all authors

R1 vs R2+ cover-letter protocol

The template above is the R1 convention: a standalone editor cover letter (200-400 words).

On an R2+ round (second revision onward), do not write a separate cover letter. Whatever you would say to the editor — the greeting and the brief change summary — belongs in the head of the response-to-reviewers letter, not in a second document. A standalone cover letter that merely restates the response letter's summary reads as redundant and, on later rounds, as boilerplate. If an earlier round already produced a cover_letter_R1.md, move it to _superseded/, exclude it from the R2+ package, and reuse the response-letter head verbatim in any portal "cover letter" field. (Exception: a journal that explicitly requires a separate cover letter at every round — then keep the head summary and the cover letter from duplicating each other.)

Response-letter head (R2+) — placed at the top of response_to_reviewers_R[N].md, before the point-by-point:

Dear Dr. [Editor Name / "Editor-in-Chief"],

Thank you for the opportunity to revise our manuscript once more. In brief, this
revision [1-2 sentence summary of the principal changes — e.g., "adds the requested
subgroup analysis and tempers the three comparisons the reviewers flagged as
over-stated"].

[If applicable: one sentence on a companion paper, a re-analysis, or a verification
the editor requested.]

All quotations below are from the revised manuscript. A point-by-point response to each
comment follows.

Sincerely,
[First Author Name], on behalf of all authors

Keep the head to a short greeting, a one-paragraph "in brief," an optional companion/verification note, the single line stating quotations are from the revised manuscript, and the signature. Everything else is point-by-point.

---

Step 6: Change Log

Output location: revision/R[N]/change_log_R[N].md

---

Step 7: Final Verification

After all responses are drafted, check:

• [ ] Every reviewer comment has a response (none skipped)
• [ ] Every MAJOR comment has a corresponding manuscript change with location
• [ ] Every REBUTTAL is backed by cited evidence or clear scientific reasoning
• [ ] All new statistics include 95% CI and exact p-values
• [ ] Page/line number references match the revised manuscript (not the original)
• [ ] No internal draft line numbers ("(line 43)"); locations point to section names or revised-manuscript page/line
• [ ] No § symbols and no editing-mechanism narration ("v2 adds one sentence", "grep verification", "No further manuscript change")
• [ ] Acknowledgment openers varied (not one sentence repeated across responses)
• [ ] Response letter AND cover letter ran through /humanize (patterns 22-24 triage hits reviewed; confirmed instances = 0; § = 0 hard)
• [ ] (R2+) No separate cover letter — the editor greeting and "in brief" summary are folded into the response-letter head
• [ ] (R2+) Satisfied reviewers get ≤1-2 sentences; no pre-emptive hand-holding or cross-reviewer lobbying
• [ ] Multi-point reviewer paragraphs are split into discrete comments (reviewer sentence quoted + Response N), not answered as a block
• [ ] Methodology disclosure (multiplicity, SAP deviation) is folded into the relevant response, not a separate front section
• [ ] Cover letter is addressed to the correct editor
• [ ] Response letter is 5000-8000 words
• [ ] Tracked changes are enabled in the revised manuscript
• [ ] All new figures/tables are referenced in the response letter

---

Revision Round File Structure

Revised manuscript: paper/main_revised_R[N].tex (or .qmd)

For R2+, acknowledge whether R1 concerns were fully resolved. If a reviewer raises a new concern at R2, note: "This comment was not raised in the first review round; we address it as follows."

---

Word Count Guidance

• Response letter total: 5000-8000 words (including quoted reviewer comments)
• Cover letter: 200-400 words (R1 only; on R2+ there is no separate cover letter — see Step 5)
• MINOR response: 50-150 words
• MAJOR response: 150-400 words
• REBUTTAL response: 200-500 words
• R2+ rounds run leaner. Most R1 concerns are already resolved, so the letter is shorter and a satisfied reviewer's response is 1-2 sentences. Do not pad an R2+ reply to reach the R1 range.

---

Common Mistakes to Avoid

1. Do not agree with every MAJOR comment without providing the actual new data or analysis. 2. Do not write vague responses ("We have revised the text accordingly") without specifying what changed and where. 3. Do not skip any comment, even if trivial or addressed elsewhere. 4. Do not reference page/line numbers from the original manuscript; use the revised version. 5. Do not begin a rebuttal aggressively; always open with acknowledgment. 6. Do not promise changes that were not actually made. 7. Do not forget to renumber figures and tables if new items were inserted.

Anti-Hallucination

• Never fabricate references. All citations must be verified via /search-lit with confirmed DOI or PMID. Mark unverified references as [UNVERIFIED - NEEDS MANUAL CHECK].
• Never invent clinical definitions, diagnostic criteria, or guideline recommendations. If uncertain, flag with [VERIFY] and ask the user.
• Never fabricate numerical results — compliance percentages, scores, effect sizes, or sample sizes must come from actual data or analysis output.
• If a reporting guideline item, journal policy, or clinical standard is uncertain, state the uncertainty rather than guessing.

---

Gates

Response-Letter Voice Reference (R2R / Rebuttal)

A reference for writing response-to-reviewers (R2R) letters and editor cover letters that read as human-written scientific argument rather than machine-generated change-logs. Use alongside the Response-Letter Voice & AI-Tell Avoidance section of the revise SKILL.md.

All examples below are synthetic (a fictional deep-learning lung-nodule CT study) and are illustrative only. They contain no real study, author, or institution.

Sources:

• matsuikentaro1/humanizer_academic principles (general AI-writing patterns)
• Register calibrated from the conventions of published point-by-point response letters

---

The core problem: the editing-mechanism register

Machine-drafted response letters narrate how the text was edited instead of the science. The result reads like a diff log: which line changed, how many phrases were swapped, what a verification pass returned. A careful reviewer reads this as auto-generated and as evidence the authors are clearing a checklist rather than engaging with the critique.

The fix is one habit: state what changed and why in plain prose, quote the new sentence, name the section — and say nothing about the mechanism by which you found or made the edit.

This targets the editing mechanism only. Narrating a new analysis you ran is the science the reviewer asked for and is welcome — e.g., "we performed a sensitivity analysis restricted to one observation per patient, and the primary findings held." The tell is describing the text-editing operation ("we softened six phrases", "v2 adds a sentence"), not describing the analysis or its result.

---

Two acceptable formats (the structure is not the problem)

Real published response letters use any of several formats, and all read as human:

• A. Free prose — "We agree. We have added to the Methods: '...'."
• B. Structured — a Response: paragraph followed by a Changes made: (or `Action taken in

the revised manuscript:) block, often with Original: '...' → Revised: '...'` before/after pairs and the section and revised-manuscript page/line.

• C. Two-column table — reviewer comment on the left, author response on the right.

Other normal conventions seen across real letters: restating the reviewer's comment before responding, and numbering multiple changes within one response as (1), (2), (3).

The AI-tell is not the structure, the tables, or the before/after pairs — careful authors write all of these. The tell is the editing-mechanism narration layered on top: version prefixes ("v2 adds..."), internal draft line numbers, grep/verification language, internal FIX codes, § markers, and bare "No further manuscript change" stubs. Keep whichever format you like; strip the mechanism.

---

Before / after gallery

1. Version-prefixed change narration + internal line numbers

Reviewer: The causal language overstates an observational design.

AI-tell (bad): "v2 Methods §Design (line 43) adds one sentence: 'The user/non-user contrast is reported descriptively and is not interpreted as evidence of efficacy.' This is a short visible clarification in the manuscript body rather than only in the Limitations."

Natural (good): "We agree. The design is observational, so we have added a sentence to the Methods (Design subsection) making the descriptive intent explicit: 'The user/non-user contrast is reported descriptively and is not interpreted as evidence of efficacy.' The corresponding causal phrasing in the Results has been removed."

Why: the natural version keeps the quoted new sentence and a section-name pointer but drops the version prefix, the § marker, the internal line number, and the meta-commentary about where the clarification sits.

2. Tooling / verification leak

Reviewer: Several results are described as "numerical trends," which is speculative.

AI-tell (bad): "A grep-and-soften pass replaced six phrases. Final grep verification across the manuscript and the circulated supplementary tables returned zero occurrences of 'numerical trend', 'consistent direction', or 'possible relationship'."

Natural (good): "We have rephrased these passages so that non-significant point estimates are no longer presented as trends. For example, 'users showed a numerically larger reduction' now reads 'the point estimate favoured the user arm, but the 95% confidence interval crossed zero and is uninformative for inference.'"

Why: the reviewer cares about the corrected wording and the principle behind it, not that the authors ran a search to confirm the strings were gone.

3. Redundant "no change" stubs

Reviewer: Retention was low.

AI-tell (bad): "This was already reported in v1. No further manuscript change was applied."

Natural (good): "We have kept the retention figure but moved it to the front of the Conclusions so it leads the feasibility assessment rather than appearing as an aside: the final retention of 58% fell short of the 80% target and is the binding constraint on the present pilot."

Why: even when little changes, reply with substance. A bare "no change" stub repeated across comments is a hallmark of checklist-driven drafting.

4. Uniform openers

AI-tell (bad): every response begins "We thank the reviewer for this important suggestion."

Natural (good): vary by stance —

• "We agree, and have revised accordingly."
• "This is a fair concern about generalisability."
• "We see how the original wording invited this reading; we have corrected it."
• "We respectfully maintain the original analysis, for the reasons below."

5. Admitting an error

AI-tell (bad): "v3 corrects the acquisition-time value at line 211 per the reviewer's observation."

Natural (good): "The reviewer is correct. During revision we found an error in the reported acquisition time; the correct value is 15 s per phase. We have corrected this in the Methods and apologise for the oversight."

6. Tempering an over-claim (the most common revision task)

Reviewer: Several results are described as "significantly outperformed," but the confidence

intervals overlap; this overstates the evidence.

AI-tell (bad): "v2 grep-and-soften pass replaced 'significantly outperformed' at lines 14, 88, and 203. Final grep verification across the circulated manuscript returned zero occurrences of 'significantly', 'consistent direction', or 'numerical superiority' (§Results, §Discussion). FIX-2 vocabulary cascade applied."

Natural (good): "We fully agree. Given the overlapping 95% confidence intervals, 'significantly outperformed' overstated the evidence. We have tempered this language in the Abstract, Results, and Discussion to describe the difference as a modest, consistent improvement rather than a statistically significant one. For example, in the Results: Original: 'the 2.5D model significantly outperformed the 2D model.' Revised: 'the 2.5D model achieved a modestly higher C-index (0.71 vs 0.68); the confidence intervals overlap, so this is a consistent but not statistically significant difference.'"

Why: the natural version makes the same correction the reviewer asked for, shows the exact before/after wording, and names the affected sections — without the grep narration, the internal line numbers, the § markers, or the internal FIX label.

---

Succinctness & non-defensiveness (R2+)

Items 1-6 strip the editing-mechanism tell. These strip the defensive over-elaboration tell, which dominates later (R2+) rounds: pre-emptive lobbying, manufactured paragraphs for satisfied reviewers, and disclosure piled into a front section. The fix is always to say less and let the point-by-point carry the work. (Examples remain synthetic — a fictional imaging deep-learning study.)

7. Pre-emptive hand-holding / cross-reviewer lobbying

AI-tell (bad): "We respectfully note that Reviewers 1 and 3 found this analysis appropriate, and we left the primary endpoint unchanged on that basis. We hope Reviewer 2 will agree that the consensus of the panel supports our approach."

Natural (good): "We retained the primary endpoint as pre-registered. Our reasoning is [one-sentence scientific justification]; we have added it to the Methods: '[new sentence].'"

Why: answer the reviewer in front of you on the merits. Citing what other reviewers thought is lobbying, not science, and reads as defensive.

8. Defensive meta-comment about an unchanged passage

AI-tell (bad): "We confirm that this statement is unchanged and has not been softened or weakened in any way, and we emphasise that it already fully conveys the intended claim."

Natural (good): "This is already stated in the Discussion: '[existing sentence].'"

Why: point to where the matter is handled and stop. Insisting that nothing was weakened invites the suspicion that something was.

9. Over-elaborated response to a satisfied reviewer

Reviewer: The revised manuscript is much improved and I have no further concerns.

AI-tell (bad): "We are deeply grateful to the reviewer for this generous assessment. It has been a privilege to benefit from such careful and constructive guidance throughout, and we are delighted that the substantial revisions across the Methods, Results, and Discussion have fully addressed the concerns raised in the previous round."

Natural (good): "Thank you."

Why: a satisfied reviewer needs one sentence. A paragraph of gratitude is padding and reads as machine-generated filler.

10. Methodology disclosure as a separate front section

AI-tell (bad): A standalone "Statistical Note" at the top of the letter: "Before responding to individual comments, we wish to disclose that the subgroup analyses were not adjusted for multiplicity..."

Natural (good): inside the response to the comment that raised it — "The reviewer is right to ask about multiplicity. These subgroup analyses were exploratory and are not adjusted for multiple comparisons; we now state this in the Methods and label them as exploratory in Table 3."

Why: keep the disclosure (never hide a deviation) but put it where the reviewer raised it. A front-loaded "note" separates the admission from the question and reads as pre-emptive defence.

11. Bundling a multi-point paragraph into one block reply

Reviewer: The introduction is too long, the cohort definition is unclear, and Figure 2 is

hard to read.

AI-tell (bad): "We thank the reviewer for these helpful comments. We have shortened the introduction, clarified the cohort, and improved Figure 2 accordingly."

Natural (good): split into three — "Comment 1. 'The introduction is too long.' We have cut the introduction by roughly a third, removing [what]. … Comment 2. 'The cohort definition is unclear.' We have added to the Methods: '[new sentence].' … Comment 3. 'Figure 2 is hard to read.' We have remade Figure 2 with [change]. …"

Why: each sub-point gets a quoted comment and a specific response. A single block reply hides which point you actually addressed and which you skipped. Succinct means short answers, not fewer comments.

---

Three response skeletons

Pick the skeleton that matches the comment's substance; do not force every reply into one shape.

A. Full agreement (most common)

[quote the reviewer comment]

"We agree. We have [substantive change] in the [section]. The revised text reads: '[new sentence verbatim].'"

Keep it to 2-5 sentences. Quote the new text; name the section; stop.

B. Partial agreement with a bounded clarification

[quote the reviewer comment]

"The reviewer raises a valid point about [aspect]. We have [the part you accept] in the [section]. We have not [the part you decline] because [specific scientific reason]; instead, we [the bounded alternative], which addresses the underlying concern without [the cost of the full request]."

C. Polite, evidence-backed rebuttal

[quote the reviewer comment]

"We understand the concern that [restate the reviewer's point fairly]. We respectfully maintain [your position] because [reasoning grounded in the data or design]. [If literature supports you: 'This is consistent with (Author, Year), who showed ...'] To make this clearer to readers, we have added a sentence to the [section]: '[new sentence].'"

Never open a rebuttal combatively, and never write "the reviewer is wrong." Frame disagreement as a shared interest in getting the interpretation right.

Graceful defer (when you decline an addition but want to leave the door open)

"We considered [the requested addition], but believe [the change already made] adequately addresses the underlying concern without [the cost]. If the reviewer prefers, we are happy to add [the requested item] in a subsequent revision."

This is a common, courteous move: it shows you took the request seriously, gives a reason, and defers rather than flatly refusing.

Response-letter head (R2+)

On R1 the editor gets a separate cover letter; on R2+ there is no separate cover letter — its content becomes the head of the response letter. Keep the head to a short greeting, a one-paragraph "in brief" summary of the principal changes, an optional one-sentence companion/verification note, the single line stating that all quotations are from the revised manuscript, and the signature. Then go straight to the point-by-point.

"Dear Dr. [Editor], thank you for the opportunity to revise our manuscript once more. In brief, this revision [1-2 sentence change summary]. All quotations below are from the revised manuscript; a point-by-point response follows. Sincerely, [First Author], on behalf of all authors."

Reuse this head verbatim in any portal "cover letter" field rather than writing a second document.

---

Meta-phrase to natural-expression conversion

---

Location-pointer rule

• Point to changes by section name ("in the Methods, Statistical analysis subsection").
• A revised-manuscript page and/or line number is acceptable and common ("Methods, page 7,

lines 177-178") when those numbers refer to the revised manuscript the reviewer is reading (state once at the top: "all page and line numbers refer to the revised manuscript"). This is a normal human convention, not an AI-tell.

• What is banned is the internal markdown/draft line number ("line 43" pointing into your

working file) — it will not match the reviewer's PDF and reads as a diff log. If you cannot guarantee the line number matches the reviewer's manuscript, use the section name only.

• When the change is a sentence or two, quote the new text in quotation marks. This is

concrete, verifiable, and reads as the work of an author who knows their own manuscript.

• For larger changes (a new paragraph, a restructured subsection), summarise the change in

one sentence and point to the section; do not transcribe the whole block.

---

Pre-submission checklist (response letter + cover letter)

• [ ] grep -c "§" = 0
• [ ] No internal line-number references ("(line NN)", "at lines N, M, ...")
• [ ] No version-prefixed change narration ("v2 adds...", "the v3 revision demotes...")
• [ ] No tooling/verification leak ("grep", "softened N phrases", "circulated bundle", internal FIX labels)
• [ ] No bare "No further manuscript change" stubs — each reply carries substance
• [ ] Openers varied across responses
• [ ] New manuscript text quoted verbatim where a sentence-level change was made
• [ ] Em dashes below threshold (see humanize Pattern 13)
• [ ] Ran /humanize on both documents; triage hits reviewed, confirmed patterns 22-24 instances = 0 (§ = 0 hard)
• [ ] (R2+) No separate cover letter; its summary is folded into the response-letter head
• [ ] Satisfied reviewers answered in 1-2 sentences; no cross-reviewer lobbying or defensive meta-comments
• [ ] Multi-point reviewer paragraphs split into discrete, individually quoted comments
• [ ] Methodology disclosures folded into the relevant response, not a separate front section