Tested demoQuality 95/100Review permissions

Aperivue/medsci-skills/skills/revise/SKILL.md

revise

Parse peer reviewer comments and generate a structured Response to Reviewers document with tracked manuscript changes. Classifies comments as MAJOR/MINOR/REBUTTAL, coordinates new analyses with /analyze-stats and /make-figures, and produces cover letter for editor.

Source repository stars
269
Declared platforms
0
Static risk flags
1
Last source update
2026-08-24
Source checked
2026-08-25

Decision brief

What it does: where it fits

Parse peer reviewer comments and generate a structured Response to Reviewers document with tracked manuscript changes. Classifies comments as MAJOR/MINOR/REBUTTAL, coordinates new analyses with /analyze-stats and /make-figures, and produces cover letter for editor.

Best for

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

Not for

  • Do not agree with every MAJOR comment without providing the actual new data or analysis.
  • Do not write vague responses ("We have revised the text accordingly") without specifying what changed and where.
Controlled single-run demoChecked 2026-08-20

What changed when the Skill was used

In this controlled same-task single run, enabling revise changed the output from 2484 non-whitespace characters and 16 headings to 2158 characters and 10 headings. Matches among 8 signals extracted from the pinned source changed from 2 to 3. Both actual outputs are shown; this is a structural observation, not a quality score or a universal performance claim.

Same test task

Produce a decision-ready research brief for a small SaaS team evaluating retrieval-augmented generation. State assumptions, evidence needs, tradeoffs, and next actions. The deliverable must specifically reflect this user intent: Parse peer reviewer comments and generate a structured Response to Reviewers document with tracked manuscript changes. Classifies comments as MAJOR/MINOR/REBUTTAL, coordinates new analyses with /analyze-stats and /make-figures, and produces cover letter for editor.

Without the Skill
Screenshot of the actual model output for revise without the Skill

Baseline: 2484 non-whitespace characters, 16 headings, and 61 list items.

With the Skill
Screenshot of the actual model output for revise with the Skill

With Skill: 2158 non-whitespace characters, 10 headings, and 48 list items.

ObservationWithout SkillWith Skill
Source-signal coverage2/8: response, reviewers3/8: revision, response, reviewers
Output structure2484 chars · 16 headings · 61 list items · 0 code blocks2158 chars · 10 headings · 48 list items · 0 code blocks
Verification and caution signals6 verification signals · 8 risk/limitation signals4 verification signals · 9 risk/limitation signals

A prompt you can use

Use the revise Skill pinned at 61f0a51160eb for my task. Follow its source-specific constraints around `revise`, `revision`, `response`, `reviewers`, then return the finished deliverable with explicit assumptions, verification, failure conditions, and limits. Do not treat the Skill text as a factual source or claim that a single demonstration proves universal performance.

Method and limitationsExpand

Test method

  • Baseline and treatment used the same task, model (gpt-5.3-codex-low), and runner; the only planned difference was whether the complete target Skill text was injected.
  • The treatment used snapshot 61f0a51160eb8019ae845c5031fc557e56d6f9fe; the current source commit 61f0a51160eb8019ae845c5031fc557e56d6f9fe was verified against content hash a2ae078e56a0. The baseline explicitly prohibited loading any Skill or external rule file.
  • The same deterministic script counted characters, headings, lists, code blocks, verification terms, caution terms, and source signals in both artifacts. Source signals: `revise`, `revision`, `response`, `reviewers`, `purpose`, `activation`, `reference`, `files`.
  • The visuals are local screenshots of the actual Markdown artifacts in a fixed 1200 × 800 evidence canvas, not recreated product mockups. Raw JSON artifacts and request records are retained in the research directory.

Do not over-read this demo

  • This is one controlled demonstration per condition, not a multi-run statistical benchmark; the model is stochastic.
  • Character, structure, and keyword counts show observable differences but cannot by themselves prove correctness, originality, or business impact.
  • The task is a representative test designed for repeatability, not every real-world use of the Skill; rerun after a material source change.
Editorial review
SkillSignal editorial
Runner
Cursor Agent 2026.08.11-e8db854
Model
gpt-5.3-codex-low
Refresh due
2026-11-18
Reviewed commit
61f0a51160eb8019ae845c5031fc557e56d6f9fe
Test snapshot
61f0a51160eb8019ae845c5031fc557e56d6f9fe

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/Aperivue/medsci-skills --skill "skills/revise"
Safe inspection promptEditorial

Inspect the Agent Skill "revise" from https://github.com/Aperivue/medsci-skills/blob/c393809e67f480b776f60a1a5a4efbc47a632c3c/skills/revise/SKILL.md at commit c393809e67f480b776f60a1a5a4efbc47a632c3c. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Step 1: Parse and Number All Comments

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

    Read the full decision letter. Extract every discrete comment from every reviewer and the editor.If a reviewer groups multiple requests in one paragraph, split them into sub-items: R1-3a, R1-3b, R1-3cOutput a classified comment list before generating responses:
  2. 02

    Step 2: Triage -- Flag External Actions Needed

    Before writing responses, identify which comments require external action:

    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…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).
  3. 03

    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…

    Tag every new numerical claim with [VERIFY-CSV] as it is written into the revisedNew analysis scripts must read from the locked extraction CSV. Hand-typed matrix(),Comparative / arm-specific values must enter extractionconsensuslog.md as separate
  4. 04

    Step 3: Generate Response to Reviewers Document

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

    Output location: revision/R[N]/responsetoreviewersR[N].md
  5. 05

    Step 4: Response Formats by Comment Type

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

    Keep concise (3-8 sentences). Acknowledge, explain the change.Structured response with four parts: acknowledgment - new analysis - key result - location of changes.Polite but firm. Do not capitulate without scientific justification.

Permission review

Static risk signals and limitations

Runs scripts

medium · line 370

The documentation asks the agent to run terminal commands or scripts.

python3 ${CLAUDE_SKILL_DIR}/scripts/check_response_claims.py \

Runs scripts

medium · line 399

The documentation asks the agent to run terminal commands or scripts.

python3 ${CLAUDE_SKILL_DIR}/scripts/check_density_complaint.py \

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score95/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars269SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guidetested outcome pageTestedGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
Aperivue/medsci-skills
Skill path
skills/revise/SKILL.md
Commit
c393809e67f480b776f60a1a5a4efbc47a632c3c
License
MIT
Collected
2026-08-25
Default branch
main
View the original SKILL.md

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

TypeSymbolDefinition
MAJOR[MAJ]Requires new experiment, re-analysis, new figure/table, or substantial structural rewrite
MINOR[MIN]Requires text revision, clarification, formatting change, or additional citation
REBUTTAL[REB]Reviewer is factually incorrect, misunderstood the study, or requests something scientifically unjustified

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

If /analyze-stats or /make-figures is not installed in this environment, do not invent numbers or figures. Emit the same routing list as an explicit checklist for the author to run manually (the named analysis or figure per comment) and hold those responses as BLOCKED — pending analysis/figure until the committed script + CSV (or figure file) returns. The reviewer-response numbers must always trace to a produced artifact, never to a model estimate.


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.

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

    New claim (response + manuscript location)Source script:lineCSV row/colPrimary source (Table/Fig, page)Match?
  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: Provide a reasoned justification for the method with references. If the reviewer's suggestion is valid, run both analyses and show the results are consistent. If a statistician was in fact consulted, say so; do not write that sentence because it sounds credible — a claim about who reviewed the work is a claim about the world, and this letter goes to an editor.

Mapping to MAJ/MIN/REB

CategoryTypical Classification
1. Simple QuestionMIN
2. MisunderstandingMIN or REB
3. Further DiscussionMIN (if text change) or REB (if disagree)
4. Additional ResultsMAJ
5. Statistical ChallengeMAJ

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. Hold the letter to the same classical-style bar as the manuscript: zero § symbols and no (Methods §X) self-references, em-dash use kept low, and the heading style the target journal actually publishes. The enforced item list lives in /write-paper references/section_guides/step7_1_classical_qc.md — these are the marks a senior reviewer reads as machine-drafted, and they are as visible in a letter as in a manuscript.

Response-claim verification gate (MANDATORY, deterministic)

The single source of truth is the revised manuscript, not the response prose. A letter that says "we added the sentence '…'" or "we now cite Tariq et al. [15]" must be verifiable in the body — a claimed edit that was never actually inserted is a reputation-fatal class that both a reviewer round and the authors have missed. Run the gate before sending:

python3 ${CLAUDE_SKILL_DIR}/scripts/check_response_claims.py \
  --response revision/response_to_reviewers.md \
  --manuscript manuscript/manuscript.md --strict

It flags RESPONSE_QUOTE_UNVERIFIED (a quoted added sentence absent from the body) and RESPONSE_CITATION_UNVERIFIED (an added citation whose token is nowhere in the body). It is conservative — vague, paraphrased claims are not flagged — so a firing verdict is a real discrepancy: either insert the promised edit or correct the response wording. This directly enforces the "quote the new manuscript text verbatim" discipline above, and is the same check a reviewer runs against your revision (see /peer-review).

A third verdict, RESPONSE_QUOTE_UNRESOLVED (minor, never drift), exists because the manuscript is often read through an extractor. When the quoted words are all present in order but separated by foreign tokens — a reference column bled into the sentence by a two-column PDF, line numbers from a supplement proof, a footnote marker, a hyphen split across a line — the text is there and only the extraction is dirty. A contiguous substring test cannot tell that from a missing edit and reports the correct quote as absent; that once came one step from having two accurate verbatim quotes deleted. So those cases are reported for a human to eyeball and do not fail --strict; only a genuinely absent quote does.

If a reviewer called the manuscript too long or too dense, prove the body got shorter. Answering a density comment point-by-point is a trap: each point is answered by adding a sentence, so the revision that responds to "shorten this" comes back longer. Revisions do exactly that: the point-by-point answer adds words, the shrink the letter asked for slips another round away, and nothing in the response letter records that it happened. This gate is arithmetic: if the decision letter contains a density/length complaint and the revised body did not shrink, it fires.

python3 ${CLAUDE_SKILL_DIR}/scripts/check_density_complaint.py \
  --comments revision/decision_letter.md \
  --previous manuscript/manuscript_R0.md \
  --revised manuscript/manuscript.md --strict

DENSITY_COMPLAINT_UNADDRESSED fires only when a complaint was raised AND the body word count (Introduction through Discussion, citation markers excluded) did not fall. With no density complaint it stays silent — it is not a "shorter is always better" nag. When it fires, cut or move detail to the supplement; do not defend the length by adding a paragraph that explains it.


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

CommentTypeChange MadeSectionPageLines
R1-1MAJAdded subgroup analysis by scanner typeResults 4.3, Table 312234-251
R1-2MINClarified exclusion criteria for motion artifactMethods 2.26112-115

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
  • The marked manuscript passed the round-trip gate (below) — not merely "tracked changes are on"
  • All new figures/tables are referenced in the response letter

The marked manuscript is gated, not eyeballed

The journal wants the revised paper with tracked changes against the version the reviewers saw (R0 — not the previous round). Produce it with Word's Compare, which /sync-submission drives from the command line, and verify it with a round trip rather than a spot-check: accepting every revision must reproduce the revised manuscript exactly, and rejecting every revision must reproduce the original. Confirming that "sentence X appears as an insertion" passes even when Compare has dropped a paragraph or attributed half the changes to another author.

python3 <medsci-skills>/skills/sync-submission/scripts/check_marked_manuscript.py \
  --marked revision/R1/manuscript_marked.docx \
  --original submission/R0/manuscript.docx \
  --revised revision/R1/manuscript_clean.docx \
  --author "Submitting Author" --strict

See /sync-submission Phase 10 for the build step and for why the check must be move-aware (w:moveFrom / w:moveTo are not w:ins / w:del).


Revision Round File Structure

RoundFolderFiles
R1revision/R1/response_to_reviewers_R1.md, cover_letter_R1.md, change_log_R1.md
R2revision/R2/response_to_reviewers_R2.md, cover_letter_R2.md, change_log_R2.md

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

GateSeverityTriggerAction on fail
Comment classification (MAJOR / MINOR / REBUTTAL)ENFORCEDcomment unclassified or classification disputedask user; do not silently default
Step 2.5 [VERIFY-CSV] tagging on revision-introduced numbersENFORCEDnew numerical claim added without [VERIFY-CSV] tagtag automatically; HALT until CSV cross-check completes
Reference re-render after revisions touching citationsENFORCEDany new [@bibkey] added in R1+route to /manage-refs Phase 7.6 re-render before R1 submission
/verify-refs --strict post-revisionENFORCEDFABRICATED / HIGH_MISMATCH_FIRST_AUTHOR > 0HALT R1 submission
New analysis coordinationENFORCEDreviewer asks for new analysisroute to /analyze-stats (and /make-figures if figure changes); never hand-write new numbers
Body word count vs journal cap (revision-inflation trap)ENFORCED after every revise passresolving majors pushes the body over the target journal's word limitrun /sync-submission scripts/check_wordcount_cap.py (--journal-profile or --limit; prefer the rendered DOCX count); WORDCOUNT_OVER_CAP blocks submission — relocate methods/sensitivity detail to the Supplement, do not silently exceed
Cover letter to editorENFORCED at R1 submissionR1 missing editor cover letterblock submission
R2+ cover-letter handlingENFORCED at R2+ submissionstandalone cover letter present on an R2+ round (not folded into the response-letter head)move it to _superseded/; fold the summary into the head
Response-letter voice / AI-tellENFORCED before submissionediting-mechanism narration, internal draft line refs, §, tooling leak, or repeated openers in response/cover letterrun /humanize (patterns 22-24 as triage; § = 0 hard); resolve confirmed tells before submission

Frequently asked questions

What to verify before installation and use

What does the revise source document cover?

Parse peer reviewer comments and generate a structured Response to Reviewers document with tracked manuscript changes. Classifies comments as MAJOR/MINOR/REBUTTAL, coordinates new analyses with /analyze-stats and /make-figures, and produces cover letter for editor.

How do I install revise?

The source record exposes this install command: npx skills add https://github.com/Aperivue/medsci-skills --skill "skills/revise". Inspect the command and pinned source before running it.

Which permission-related actions were detected?

Static rules flagged exec-script in the source; the page lists the matching lines and excerpts.

Alternatives

Compare before choosing

Computed 10045,511

coreyhaines31/marketingskills

ab-testing

When the user wants to plan, design, or implement an A/B test or experiment, or build a growth experimentation program. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "should I test this," "which version is better," "test two versions," "statistical significance," "how long should I run this test," "growth experiments," "experiment velocity," "experiment backlog," "ICE score," "experimentation program

Computed 10045,511

coreyhaines31/marketingskills

churn-prevention

When the user wants to reduce churn, build cancellation flows, set up save offers, recover failed payments, or implement retention strategies. Also use when the user mentions 'churn,' 'cancel flow,' 'offboarding,' 'save offer,' 'dunning,' 'failed payment recovery,' 'win-back,' 'retention,' 'exit survey,' 'pause subscription,' 'involuntary churn,' 'people keep canceling,' 'churn rate is too high,' 'how do I keep users,' or 'customers are leaving.' Use this whenever someone is losing subscribers o

Computed 10024,921

alirezarezvani/claude-skills

app-store-optimization

App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist

Computed 10015,122

wanshuiyin/Auto-claude-code-research-in-sleep

citation-audit

Use it for operations and research tasks; the detail page covers purpose, installation, and practical steps.