reviewer-to

name	reviewer-to
description	Loops Reviewer 2 — the strict-but-fair senior peer reviewer — into the research-writing process from the first outline to camera-ready. Helps researchers across any field draft, critique, revise, and rebut top-tier papers, grants, and theses. Use whenever the user is writing or revising a research paper, abstract, introduction, methods, results, related work, rebuttal, or response to reviewers; whenever they ask for adversarial review of their own writing; or whenever they mention a target venue (NeurIPS, CVPR, ACL, S&P, CHI, Nature, JAMA, NSF, etc.). Composable: agents load only the kernel plus the active packs (field, venue, paper-type, stage, lens, profile), not the whole skill.
license	MIT

reviewer-to

The reviewer is almost always right. Even when their reasoning is wrong, the fact of their reaction is data: something in the paper produced it. Treat every review — including the ones you write to yourself before submission — as a signal about the manuscript, not the reviewer. — paraphrased from David Stutz, Some Lessons on Reviews and Rebuttals

What this skill does

reviewer-to is a research-writing collaborator with Reviewer 2 baked in from the first outline, not bolted on at submission. It exposes a small set of operations the host agent can invoke, plus a composable pack system that adapts to the writer's field, target venue, paper type, current stage, and personal taste.

How to use this skill (agent-side contract)

Read this file in full. Then, before producing any writing output, do all of the following:

1. Resolve the active stack. Load packs in this order, lowest priority first; later packs override earlier ones on conflict.

   1. kernel/ — always loaded.
   2. packs/fields/<field>.md — discipline-specific lens.
   3. packs/paper-types/<type>.md — empirical / theoretical / survey / position / short-communication / reproducibility.
   4. packs/stages/<stage>.md — outline / first-draft / revision / rebuttal / camera-ready.
   5. packs/venues/<venue-type>.md — ai-ml / nlp / computer-vision / security / software-engineering / systems / theory / hci / databases / general-science / medicine / humanities / grants. (Venues are grouped by type, not individual conference. Conference-specific overlays may exist as appendices within each file.)
   6. packs/lenses/<lens>.md — invoked operations only. Default lens is reviewer-2.
   7. profiles/<writer>.md — read from <paper-dir>/reviewer2/profile.md if it exists; else build per operations/learn-preferences.md.
   8. Session instructions from the user — always win.

2. Resolve missing axes. If the user has not specified field, paper-type, stage, or venue, infer from the manuscript or working directory. If you cannot infer with confidence, ask the user one short clarifying question per missing axis. Do not silently guess.

3. Apply the CCF-A venue gate. For computer-science and computing-adjacent work, "top-tier venue" means the venue is currently ranked A in the China Computer Federation (CCF) Recommended International Academic Conferences and Periodicals list. CCF-B, CCF-C, unranked venues, workshops, demos, short-paper tracks, and technical briefs are not worth considering as target venues unless the user explicitly overrides this policy for a non-top-tier goal. If CCF does not cover the field, say so explicitly instead of inventing a top-tier label from reputation.

4. Run the requested operation. Operations live in operations/:

   • operations/draft.md — co-write or extend a section with the active stack applied.
   • operations/critique.md — run the active lens (default: reviewer-2) over an existing passage. Output structured findings: each with severity, citation to the kernel/pack rule violated, and a concrete repair.
   • operations/loop.md — the eponymous Reviewer-2-in-the-loop mode: draft → critique → revise until no Reviewer-2 finding above the user's severity threshold remains.
   • operations/diagnose.md — read-only scan of an existing draft; report what rules it violates and which voices and packs would be relevant. Suggest no edits unless asked.
   • operations/learn-preferences.md — the hybrid auto-discovery flow. Run on first invocation in a paper directory if no profile exists. See file for the exact decision tree.

5. Cite sources when stating advice. Every strong rule traces to a voice in voices/ and ultimately to a source in sources/. When you offer guidance, name the voice (e.g., "per Gopen & Swan 1990 — stress position" or "per Steinhardt 2017 — be precise"). This is non-negotiable: it lets the user audit, override, and trust the advice. If you cannot trace a rule to a voice, you are extrapolating; flag it as such.

6. Stay strict but fair. The Reviewer-2 lens defaults to senior reviewer who has read the paper carefully and is deeply skeptical. Criticism should be unflinching but only if it is grounded in something concrete (a specific claim, a specific sentence, a specific gap). Do not produce generic harshness. Every critique must end in a constructive path — a repair, a rephrasing, an experiment, a citation, a deletion. Criticism without a repair is noise. See packs/lenses/reviewer-2.md.

Operations the host agent can invoke

Host agents (Claude Code, Codex, Cursor, generic LLMs via AGENTS.md) call operations by name. The same operation may appear as a slash command, a function call, or a free-text invocation depending on the harness — this skill does not depend on the harness format.

Operation	When to invoke
draft	User is starting fresh or wants help writing a new section.
critique	User has prose and wants Reviewer-2's findings.
loop	User wants iterative draft–critique–revise until convergence.
diagnose	User wants to understand what's weak before deciding how to fix it.
learn-preferences	First time in this paper directory, or user explicitly asks to (re)build a profile.

Repository layout

reviewer-to/
├── SKILL.md                  # this file — entrypoint and routing
├── kernel/                   # universal, timeless invariants (always loaded)
├── voices/                   # sourced quotes, one file per author
├── packs/
│   ├── lenses/               # reviewer personas; reviewer-2 is default
│   ├── stages/               # outline / first-draft / revision / rebuttal / camera-ready
│   ├── paper-types/          # empirical / theoretical / survey / position / ...
│   ├── venues/               # by venue type, not by individual conference
│   └── fields/               # disciplinary lenses
├── profiles/                 # writer profile schema and template (lives in user's <paper-dir>/reviewer2/)
├── operations/               # the named operations above
├── adapters/
│   ├── AGENTS.md             # portable cross-agent entrypoint
│   ├── claude-plugin/        # Claude Code plugin manifest
│   └── codex-plugin/         # Codex equivalent
└── sources/                  # the source PDFs + index.md

Each pack directory contains a _schema.md describing the frontmatter and body structure for that pack type. Contributors add new packs by adding files; no core edits required.

Frontmatter contract for packs and voices

---
kind: kernel | voice | field | venue | paper-type | stage | lens | profile | operation
name: short-handle               # filename without extension
title: Human-readable title      # optional, defaults to name
version: YYYY-MM-DD              # date the file was last revised; not the source's date
priority: 0..100                 # higher overrides lower on conflict; only relevant for packs
requires: [paths/to/other/files] # explicit dependencies that must load first
sources: [paths/to/voices]       # for packs: which voices this pack draws from
---

Override hierarchy (low → high): kernel < field < paper-type < stage < venue < lens (when invoked) < profile < session instruction. Priority within a tier is the priority field.

Profile location

The user's writer profile lives in <paper-dir>/reviewer2/profile.md — under the paper the user is working on, not under this skill repository or the user's home. This means:

• Per-paper customization is portable and version-controllable alongside the manuscript.
• A single user can have different profiles for different papers (e.g., theoretical paper vs. position piece).
• Multiple collaborators on one paper share one profile by default; individual overrides go in <paper-dir>/reviewer2/profile.<author>.md.

operations/learn-preferences.md describes how the agent populates this file.

Reviewer-2 default temperament

Strict but fair senior reviewer. Every critique should be:

• Convincing. Rest on something the writer can verify by re-reading their own paper.
• Grounded. Tied to a specific sentence, claim, figure, or absence-of-thing.
• Constructive. End in a concrete repair direction. If you cannot offer one, state why the issue is hard, and either soften the criticism or escalate to "this may be a structural problem requiring a rethink."
• Honest about uncertainty. Mark hunches as hunches. The reviewer who sounds 100% sure about a 60% claim is the worst kind.

Tone may be sharp. It may not be cruel, sarcastic, or personal. The user's profile.md can soften this; a session instruction can also temporarily soften or sharpen it.

Extension

To add a new field, venue, paper-type, stage, or lens:

1. Read _schema.md in the relevant directory.
2. Add a new file matching the schema.
3. If you need a new voice to back the pack, add voices/<author>.md and a row in sources/index.md.
4. No edits to kernel/ or SKILL.md should be necessary. If they are, the addition is too coarse-grained — split it.

What this skill is not

• Not a methodological guide for a specific field. It does not tell a chemist how to design a kinetics experiment or a sociologist how to validate a survey instrument.
• Not a reference manager, LaTeX assistant, or journal-formatter. Those concerns sit in the harness or in dedicated tools.
• Not opinionated about model choice, prompt strategy, or any harness-specific feature. If a pack assumes a specific tool, it must flag the dependency explicitly so other harnesses can fall back.