paper-reviewer

paper-reviewer — deep pre-submission review

A reimplementation of the Paper Assistant Tool (PAT) architecture (Jayaram et al., Google Research, arXiv:2606.28277) on Claude Code subagents in place of Gemini Deep Think.

The premise from PAT, which is what makes this skill worth more than "read the paper and criticize it": a single reading pass spends its reasoning budget uniformly and shallowly. Segmenting the manuscript, giving each reviewer the whole text as context but only one segment to verify, then consolidating with deduplication and grounding checks, raises real-error detection substantially. On the Math/CS subset of the SPOT benchmark, this orchestration took the same model from 55.2% to 89.7% detection.

It produces no score, no ranking and no accept/reject recommendation. It produces objective errors and actionable improvements.

Writing counterpart: paper-writer. Writing and reviewing are separate passes by design; whoever writes does not approve their own text in the same context.

Stage 0 — Resolve the target

1. If the user named a file, use it. Otherwise look for the most likely manuscript in the current directory (a .tex with \documentclass, or a long .md) and confirm with the user before spending agents if there is more than one candidate.
2. Accepted formats are .tex, .md, .pdf and .docx, and source beats the rest. PAT lists PDF parsing failure among its three most reported limitations, and a .docx costs a conversion the source does not. If a .tex or .md exists, use it and ignore the compiled PDF.
3. Read the whole manuscript before segmenting. Without that, the segmentation comes out wrong.
4. Locate verification inputs, if they exist:
   • the .bib or reference file;
   • data, result tables or experiment outputs in the repository (for example data/outputs/), which allow checking number by number;
   • previous reviews, audits or referee reports (for example reviews/, response_*.md, HANDOFF.md), which serve to avoid repeating a point already resolved.