Paper Review

Paper Review

A systematic approach to self-reviewing academic papers before submission, run as three passes: an adversarial deep read, a checklist sweep (5 aspects, reverse-outlining, figure/table quality), and mechanical consistency scans plus an experimental protocol audit. Ends with rebuttal preparation.

When to Use This Skill

• User wants to review or check a paper draft before submission
• User asks for feedback on paper quality or completeness
• User wants to prepare for potential reviewer criticism
• User mentions "review paper", "check my draft", "self-review"

If the user has already received reviewer comments and needs to write a rebuttal, use the paper-rebuttal skill instead.

Prerequisites

Before starting review, confirm the paper-writing handoff checklist is satisfied: all sections drafted, claims anchored to evidence, limitation section present, figures finalized, and no unresolved \todo{} markers. If any item is incomplete, finish writing before reviewing.

---

How to Run the Review: Three Passes

Run the review as three separate passes, in this order, and merge findings only at the end. Do not start from the checklists: a checklist primes you to see only what it names, and the flaws that kill papers in review are often the ones no checklist question points at.

Pass 1 — Adversarial deep read (checklists closed)

Read the paper end-to-end as a skeptical expert reviewer, before consulting any checklist in this skill. Chase cross-section threads as you read:

• Does the evidence actually support each claim at the place it is made?
• Does an assumption stated in the setup ever get revisited — or quietly violated — later?
• Do the numbers quoted in prose match the tables? Does the conclusion deliver what the abstract promised?
• Would this method survive outside the paper's exact setting?

Write down every suspicion with its location, including ones you cannot yet prove — see Calibrated Suspicion below for how to phrase and mark them. This pass is where hidden, cross-section flaws surface; no checklist replaces it.

Pass 2 — Checklist sweep

Now work through the structured materials: the 5-aspect checklist, the counterintuitive protocol, reverse-outlining, and the figure/table and conclusion checks. This pass buys breadth and catches the known, frequent failure patterns.

Pass 3 — Mechanical scans and protocol audit

Execute the Experimental Protocol Audit and the Mechanical Consistency Scans (both below) explicitly, using search/cross-referencing over the source files. The scans are search problems and the audit is a line-by-line reconstruction of the setup; both have a high hit rate — and "reading carefully" never triggers them on its own.

Merge

Union the findings of all three passes and deduplicate. A Pass-1 suspicion that no checklist item names still ships, under the confidence rules below — deduplication removes repeats, not doubts.

Reporting Findings: Calibrated Suspicion

A review finding contains two kinds of statements, with different rules:

• Factual assertions about the paper — what a table contains, what a section says, whether something is present or absent. These must be verifiable: check the text before asserting, and anchor the finding to an exact location or short quote. Never state that the paper says something it does not — one fabricated criticism costs more credibility than ten valid ones buy.
• Suspicions and judgments — "these gains may be within seed noise", "this assumption looks unrealistic in deployment". These are allowed and encouraged, including at low confidence. Phrase them as what they are: state the suspicion, mark the confidence, and name what evidence would settle it ("no variance is reported; 3 seeds would settle this").

Do not suppress a suspicion because you cannot prove it. In self-review, a hidden flaw that survives to the real reviewers costs far more than a raised-and-then-cleared suspicion. Precision discipline applies to facts, not to doubts.

---

The Perfectionist Approach

Strive for perfection: review your own paper, consider every question a reviewer might ask, and address them one by one.

The best defense against negative reviews is a thorough self-review:

1. Adversarial review: Read your own paper as a critical reviewer would
2. Seek advisor feedback: Ask your advisor to review — the more feedback, the better
3. Address everything: For every potential weakness you find, either fix it or prepare a defense

Counterintuitive Review Protocol

Run this protocol before final polishing:

1. Reject-first simulation: Force yourself to write a one-paragraph reject summary before writing any positive comments.
2. Delete one unsupported strong claim: If a strong claim lacks direct evidence, remove it instead of defending it.
3. Score trust, not only score gains: Papers with slightly lower gains but higher fairness and reproducibility often receive better review outcomes.
4. Promote one explicit limitation: Move one meaningful limitation from hidden notes into the paper; transparency can increase confidence.
5. Attack your novelty claim: Ask "Could a strong PhD derive this in one afternoon?" If yes, narrow and sharpen the novelty statement.

See references/counterintuitive-review.md

---

5-Aspect Self-Review Checklist

Aspect 1: Contribution Sufficiency

The paper does not provide readers with new knowledge.

Ask these questions to evaluate whether the contribution is sufficient:

• Are the failure cases common? If the failure cases are frequent and obvious, reviewers may question whether the method is ready for publication.
• Is the proposed technique well-explored? If the technique is already widely studied, what new insight or improvement do we bring?
• Is the improvement foreseeable / well-known? If the improvement was predictable from combining known ideas, the novelty may be questioned.
• Is the technique too straightforward? A straightforward application of existing techniques may lack sufficient contribution.

Red flag: If "yes" to any of these, strengthen the contribution narrative or add more technical depth.

Aspect 2: Writing Clarity

Missing technical details, not reproducible; a method module lacks motivation.

• Missing technical details? Would a reader be able to reproduce the method from the paper alone?
• Missing module motivation? Does every module in the Method section explain why it exists, not just what it does?
• Paragraph structure: Does each paragraph have a clear topic? Does the first sentence state the point?
• Flow: Is the logical flow between paragraphs and sections smooth?
• Terminology: Are terms used consistently throughout?

Red flag: If reproducibility is in doubt, add implementation details or supplementary material.

Aspect 3: Experimental Results Quality

Only slightly better than previous methods; or better than previous methods but still not good enough.

• Marginal improvement? If the improvement over SOTA is very small, is it statistically significant?
• Absolute quality insufficient? Even if better than baselines, is the output quality good enough for the application?
• Visual quality: Do qualitative results look convincing? Are improvements visible?

Red flag: If improvements are marginal, emphasize other advantages (speed, generalizability, simplicity) or add more challenging test cases.

Aspect 4: Experimental Testing Completeness

Missing ablation studies; missing important baselines; missing important evaluation metrics; data too simple.

• Missing ablation studies? Is every core contribution ablated?
• Missing important baselines? Are recent SOTA methods included?
• Missing evaluation metrics? Are all standard metrics for this task reported?
• Datasets too simple? Do the benchmarks truly test the method's capabilities?
• No failure case analysis? Honest failure analysis increases credibility.

Red flag: Missing ablations or baselines is one of the most common reasons for rejection.

Aspect 5: Method Design Issues

Experimental setting is impractical; method has technical flaws; method is not robust; new method's costs outweigh its benefits.

• Impractical experimental setting? Are assumptions realistic for the intended use case?
• Technical flaws? Does the method have theoretical or conceptual weaknesses?
• Not robust? Does the method require per-scene hyperparameter tuning?
• Benefit < Limitation? Does the new module introduce limitations that outweigh its benefits?

Red flag: If the method requires significant tuning per scenario, add robustness experiments or acknowledge and address the limitation.

---

Experimental Protocol Audit

The most damaging experimental flaws hide in single sentences of the setup — stated once, never revisited. Audit the experimental section line by line as a hostile auditor, not a reader:

1. Reconstruct the data flow. From the text alone, write out: what was trained on what, tuned on what, evaluated on what. Any overlap between test data and training/tuning data — including a phrase like "hyperparameters tuned on the test split" buried in the setup — is a major finding. If split hygiene cannot be reconstructed from the text at all, that is itself a finding.
2. List every assumption. Search the method and setup for "we assume", "assuming", "provided that", "given access to". For each: is it realistic at deployment time, and is its impact discussed anywhere downstream? A strong assumption stated once and never mentioned again is a major finding.
3. Check information availability. Does the method consume anything at inference time that would not exist in practice — labels, oracle signals, future information, test-distribution statistics?
4. Check the comparison protocol. Same data, same compute budget, same tuning effort for all baselines? Are baseline numbers reproduced under this paper's setup, or copied from papers with different setups?

---