Review Response GuideSAFE

🔬 A curated collection of 23,000+ agent skills for empirical research across 8 social science disciplines. | 精选 23,000+ AI Agent 技能库,覆盖8大社会科学学科的实证研究。CoPaper.AI 20分钟完成一篇可复现的规范实证论文,并支持用户上传 Skills。-- Maintained by CoPaper.AI from Stanford REAP.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: review-response-guide
description: "Craft effective point-by-point reviewer response letters"
metadata:
  openclaw:
    emoji: "✉️"
    category: "research"
    subcategory: "paper-review"
    keywords: ["reviewer response", "response letter", "revision strategy", "author reply", "manuscript revision", "editorial decision"]
    source: "wentor-research-plugins"
---

# Review Response Guide

A skill for crafting effective, professional point-by-point response letters to peer reviewer comments. Covers response letter structure, strategies for different types of reviewer feedback, prioritization of revisions, managing conflicting reviewer opinions, and navigating the revision-resubmission cycle to maximize acceptance probability.

## Response Letter Architecture

### Structural Template

A well-organized response letter follows a consistent structure that makes it easy for editors and reviewers to verify that all concerns have been addressed.

```
Response Letter Structure:

1. COVER LETTER TO EDITOR (1 page max)
   - Thank the editor and reviewers
   - Summarize the 3-5 most significant changes
   - Highlight any points where you respectfully disagree
   - Note if conflicting reviewer requests required a judgment call
   - State that all changes are marked in the revised manuscript

2. SUMMARY OF CHANGES (optional but recommended)
   - Bulleted list of all major changes
   - Brief enough to read in 2 minutes
   - Organized by theme, not by reviewer

3. POINT-BY-POINT RESPONSES
   For each reviewer, for each comment:

   ---
   REVIEWER [N], Comment [M]:

   [Quote the reviewer's comment verbatim, italicized]

   RESPONSE:
   [Your substantive response]

   CHANGES MADE:
   [Exact description of what changed, with page/line numbers
    or quoted text from the revised manuscript]
   ---

4. ADDITIONAL CHANGES (if any)
   - Changes you made that were not requested by reviewers
   - Example: "We also updated Figure 3 to use colorblind-
     friendly colors throughout."
```

### Formatting Best Practices

```
Visual formatting for clarity:

1. Use consistent fonts:
   - Reviewer comments: italic
   - Your responses: regular weight
   - Changes made: indented or in a different color

2. Numbering system:
   - R1.1, R1.2, R1.3 for Reviewer 1's comments
   - R2.1, R2.2 for Reviewer 2's comments
   - Major comments first, then minor comments

3. Cross-references:
   - When one response addresses multiple comments:
     "See our response to R1.3 above, which also addresses
      this concern."
   - When changes span multiple sections:
     "See revised manuscript, pp. 8-9, paragraphs 2-3
      (marked in blue)."

4. Length calibration:
   - Major comments: 100-300 words per response
   - Minor comments: 20-50 words per response
   - Total response letter: typically 5-20 pages
   - Longer is fine if substantive; never pad with fluff
```

## Response Strategies by Comment Type

### Methodological Concerns

```
When reviewers question your methodology:

Scenario: "The sample size is too small for the claims made."

Strong response structure:
1. Acknowledge the concern explicitly
2. Provide quantitative justification (power analysis)
3. Add additional analysis if possible
4. Acknowledge remaining limitations honestly

Example:
"We appreciate this important concern about statistical power.
We have now added a formal power analysis (Supplementary
Section S2) showing that our sample of N=120 provides 82%
power to detect the medium effect size (d=0.5) that our
hypotheses predicted, based on prior work by Chen et al.
(2021). Our observed effects were larger than this threshold
(d=0.72, 95% CI [0.41, 1.03]). We have also added a
sensitivity analysis (new Table S3) confirming that results
are robust to different analytical choices. We acknowledge
the power limitation for detecting small effects and have
added this to the Limitations section (p. 18, lines 4-8)."
```

### Requests for Additional Analysis

```
When reviewers ask for more analysis:

If feasible - do it:
  "We thank the reviewer for this excellent suggestion.
   We have conducted the requested analysis and present
   the results in new Table 4 (p. 12). The findings are
   consistent with our main results, strengthening our
   conclusions."

If partially feasible - do what you can:
  "We have conducted [part A] of the suggested analysis
   (new Figure S5). Unfortunately, [part B] is not possible
   with our current dataset because [specific reason].
   We have added this as a direction for future research
   (p. 19, line 12)."

If not feasible - explain clearly:
  "This analysis would require [data/resource] that is not
   available in our study because [reason]. However, we have
   conducted [alternative analysis] that addresses the
   underlying concern. We also now discuss this limitation
   explicitly (p. 17)."
```

### Contradictory Reviewer Requests

```
When Reviewer 1 and Reviewer 2 disagree:

This happens frequently. The key is to:
1. Acknowledge both perspectives
2. Explain your reasoning transparently
3. Ask the editor to adjudicate if needed

Example:
"Reviewer 1 suggests removing the qualitative analysis
(R1.4), while Reviewer 2 asks us to expand it (R2.7).
We believe the qualitative component adds important
context to our quantitative findings, consistent with
mixed-methods best practices (Creswell, 2018). We have
therefore retained the qualitative analysis but tightened
it from 4 pages to 2 pages, focusing on the most
illustrative quotes. We respectfully ask the editor to
advise if further adjustment is needed."

In the cover letter:
"We note a point of divergence between Reviewers 1 and 2
regarding the qualitative analysis (R1.4 vs R2.7). We have
described our proposed compromise in the detailed responses
and welcome the editor's guidance on this matter."
```

## Handling Difficult Reviews

### When a Reviewer Is Factually Wrong

```
Strategy: Correct respectfully, blame your own writing

Never: "The reviewer is incorrect a

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.