# Pnas Rebuttal > Use after PNAS reviews arrive to triage the decision, prioritize experiments, and draft a point-by-point response that is respectful, evidence-led, and honest about limits. Do not run before the main text is actually revised. - Skill: `brycewang-stanford/pnas-rebuttal` (Agent Skill) - Install (CLI): `npx skillmds add brycewang-stanford/pnas-rebuttal` - Raw SKILL.md: https://api.skillmd.com/api/skills/brycewang-stanford/pnas-rebuttal/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: brycewang-stanford (https://skillmd.com/u/brycewang-stanford) - Updated: 2026-08-19 - Page: https://skillmd.com/skills/brycewang-stanford/pnas-rebuttal --- # Reviewer Rebuttal (pnas-rebuttal) ## When to trigger - A decision letter arrives (reject / major or minor revision / accept-with-revisions). - You have reviewer comments and need a strategy before writing. - A revision is drafted and you need the point-by-point response letter. ## Step 0: read the editor's letter first The **editor's** framing outranks individual reviewers. For Direct Submissions this is the PNAS-assigned editor; for Contributed Submissions the member who communicated the paper relays the reviews. Either way, identify: - The decision type and whether a new review round is implied. - Which concerns the editor **emphasizes** (these are load-bearing — address fully). - Any **deal-breaker** the editor names (e.g., "the central claim needs independent validation"). > A "reject but would consider a new submission" is an invitation gated on the deal-breaker. Don't treat it as a flat reject, but don't under-deliver either. ## Triage every comment into 4 buckets | Bucket | Action | |--------------------|------------------------------------------------------------------| | **Do** (fair, feasible) | Make the change; show it; quote the new text/figure. | | **Do-partial** | Do what's feasible; explain the boundary with evidence. | | **Defend** (wrong/out of scope) | Push back respectfully, with data/citations — not assertion. | | **Defer** (future work) | Acknowledge; add a sentence to the text; don't over-promise. | Most rejections-on-revision come from **silently skipping** a load-bearing comment or **defending** when an experiment was actually needed. ## Prioritize the experiments - Rank requested experiments by **(impact on the central claim) × (feasibility)**. - The reviewer's #1 concern about the **main claim** must be answered with data, not prose. - If an experiment is infeasible, offer the **strongest alternative evidence** and say why it suffices. ## Response-letter format For each comment: ``` Reviewer N, Comment k: Response: . Changes: "" (p. X, lines Y–Z; new SI Appendix Fig. Sk). ``` - Open with a short thank-you and a 3–4 line summary of the **major changes** across the whole revision. - Quote each comment verbatim; never paraphrase a reviewer in a way that softens their point. - **Quote the new manuscript text** so the editor can verify without hunting. - Use a consistent visual convention (reviewer text plain, your response indented, manuscript quotes in italics/color). ## Tone rules - Respectful and non-defensive, even when the reviewer misread the paper — if they misread it, the writing was unclear; fix the writing **and** explain. - Concede real limitations explicitly; an honest limitation paragraph builds credibility. - No sarcasm, no "as we clearly stated" — assume good faith. ## Claim-integrity / over-claiming watch If a reviewer says the conclusion outruns the data, this is the **most dangerous** comment. Either add the evidence or **narrow the claim** in the title, Significance Statement, abstract, and last paragraph — and say you did. Because the **Significance Statement** is public-facing and broad, re-check it specifically for over-claiming when you narrow (link `pnas-significance`); re-run `pnas-fit` if the narrowed claim weakens broad significance. ## PNAS-specific revision ledger Build a separate ledger for the parts of a PNAS revision that reviewers and the editor can audit quickly: | PNAS surface | What to verify before response drafting | |---|---| | Significance Statement | Does the revised statement still make a broad, non-hyped contribution claim and match the narrowed evidence? | | Abstract / title | Are the public-facing claims aligned with the strongest validated result rather than the original aspiration? | | Main figures | Did each new analysis change a main-text figure, SI Appendix figure, or stated null result? | | SI Appendix | Are new robustness, data-processing, and method details findable by reviewer comment number? | | Data / code availability | Did any new dataset, software, accession number, or repository change require an updated availability statement? | When PNAS reviewers ask for extra validation, prefer a response package that shows **where** the evidence landed: "new main Fig. 3C", "new SI Appendix Fig. S7", "new Methods paragraph", or "new Data Availability sentence." Do not bury PNAS-specific changes only in the response letter. ## Output format ``` 【Decision type】 reject / reject-resubmit / major / minor 【Editor's load-bearing concerns】 [...] 【Deal-breaker】 ... → plan to resolve 【Comment triage】 Do [...] / Do-partial [...] / Defend [...] / Defer [...] 【Experiment priority】 ranked by impact × feasibility 【Claim integrity】 narrowing needed? (re-check Significance Statement + pnas-fit) 【PNAS revision ledger】 Significance Statement / SI Appendix / data-code availability changes 【Response letter】 drafted point-by-point with quoted changes ``` ## Anti-patterns - **Do not** silently skip a comment the editor emphasized. - **Do not** defend by assertion where the reviewer asked for data. - **Do not** over-promise future work to dodge a needed experiment. - **Do not** forget to update the Significance Statement and abstract if you narrow the claim. - **Do not** draft the response before the manuscript is actually revised.