Process Referee Comments

Read a reviews PDF and generate three standardised output files for managing an R&R response.

When to Use

Received reviewer reports for a paper (journal or conference)
Starting an R&R cycle and need to set up tracking infrastructure
Want to standardise an existing ad-hoc review response

When NOT to Use

Writing the actual response letter (use the generated comment-tracker.md response blocks as a starting point, then write the letter manually)
Reviewing someone else's paper (use /proofread or the peer-reviewer agent)

Inputs

Gather via interview if not provided:

Reviews PDF path — auto-discovered or user-provided (see below)
Project path — root of the research project (auto-detect from cwd if possible)
Venue slug — short identifier, e.g., ejor, facct-2026, management-science
Revision round — integer, default 1
Response deadline — date if known, otherwise "TBD"
Coordinating author — who is leading the response

PDF Auto-Discovery

Search for the reviews PDF in this order. Use the first match; if multiple PDFs found at a location, list them and ask the user to pick.

to-sort/*.pdf — most likely landing spot after download
correspondence/referee-reviews/{venue}-round{n}/*.pdf
correspondence/referee-reviews/*.pdf
Ask the user for the path if nothing found

Output Location

Review correspondence goes under correspondence/referee-reviews/, with an analysis/ subfolder for derived work:

correspondence/referee-reviews/{venue}-round{n}/
├── reviews-original.pdf              (copy of input PDF — source is NEVER moved/deleted)
├── rebuttal.md                       (empty — for response draft)
├── reviews/                          (individual reviewer files)
│   ├── reviewer-1.md
│   ├── reviewer-2.md
│   └── ...
└── analysis/
    ├── comment-tracker.md            (atomic comment matrix)
    ├── review-analysis.md            (strategic overview)
    └── reviewer-comments-verbatim.tex (LaTeX transcription)

Source PDF preservation: The original reviews PDF is only ever copied to reviews-original.pdf. Never move, rename, or delete the source file from its original location (e.g., to-sort/, Downloads, etc.). The user decides when to clean up the original.

Principle: correspondence/ holds exchanges with reviewers (their comments, your rebuttal). Internal review work (e.g., referee2 agent reports) goes in docs/{venue}/internal-reviews/.

If the round directory already exists (e.g., from manual setup), do NOT overwrite existing files. Instead:

If comment-tracker.md already exists, name the new one comment-tracker-v2.md (or next version)
If reviewer-comments-verbatim.tex already exists, name the new one reviewer-comments-verbatim-v2.tex
Always flag existing files to the user before writing

Protocol

Phase 1: Setup

Confirm inputs (PDF path, project path, venue, round, deadline, lead author)
Create the directory structure under correspondence/referee-reviews/{venue}-round{n}/
Copy the reviews PDF to correspondence/referee-reviews/{venue}-round{n}/reviews-original.pdf

Phase 2: Read the Reviews

Read the reviews PDF using the Read tool (supports PDF natively)
For large PDFs (>10 pages), read in page ranges (e.g., pages 1-10, then 11-20)
Extract for each reviewer:
- Reviewer identifier (name, number, or anonymous ID)
- Recommendation / score (if provided)
- Whether revision is allowed
- General assessment text
- Individual comments (each as a separate item)

Phase 3: Generate Individual Review Markdown Files

Create one markdown file per reviewer in reviews/:

Create the reviews/ subdirectory
For each reviewer, write reviews/reviewer-{n}.md containing:
- Header: reviewer identifier, recommendation/score, whether revision is allowed
- General Assessment: full verbatim text of the reviewer's overall assessment
- Individual Comments: each comment as a numbered item with its assigned ID (R{n}-C{m}), verbatim text, and section/page reference if mentioned
Use this template for each file:

# Reviewer {N}

**Recommendation:** {recommendation or score}
**Revision allowed:** {Yes / No / Not stated}

## General Assessment

{verbatim general assessment text}

## Comments

### R{N}-C1 {optional: section/page reference}

{verbatim comment text}

### R{N}-C2 ...

{verbatim comment text}

If files already exist in reviews/, follow the same versioning convention as other outputs (flag and version)

Phase 4: Generate LaTeX Verbatim Transcription

Using the template from templates/referee-comments/reviewer-comments-verbatim.tex:

Create one \section{} per reviewer with comment count and recommendation
Place general assessment in a genbox environment
For each specific comment:
- Assign an ID: R{reviewer}-C{comment} (sequential within each reviewer)
- Identify the section/page reference if the reviewer mentions one
- Place the full verbatim text in the comment table
If a single reviewer paragraph contains multiple distinct concerns, split into separate IDs and add a \textit{\footnotesize Split: ...} note
If any IDs are derived (split from a larger comment or inferred), add them to a Derived IDs appendix section
Compile with latexmk to verify it builds cleanly

Phase 5: Generate Comment Tracker

Using the template from templates/referee-comments/comment-tracker.md:

Fill in the Triage Summary table
Populate the Comment Matrix — one row per atomic comment:
- ID: matching the LaTeX verbatim IDs
- Reviewer: reviewer number
- Comment: short verbatim quote (first ~100 chars in quotes)
- Type: classify as Major / Minor / Editorial / Question / Praise
- Priority: assign Critical / High / Medium / Low based on:
  - Critical = threatens acceptance if not addressed
  - High = significant concern, must address
  - Medium = reasonable concern, should address
  - Low = minor or editorial
- Action: leave blank (for the user to fill)
- Owner: leave blank
- Status: set all to "Pending"
- Section: paper section referenced, if identifiable
Fill in the Status Dashboard counts
Leave Evidence Log, Patch Plan, Response Blocks, and Blockers empty (user fills during revision)

Phase 6: Generate Review Analysis

Using the template from templates/referee-comments/review-analysis.md:

Fill in Scores & Recommendations table
Write a Reviewer Profile for each reviewer:
- Posture: hostile / sceptical / constructive / supportive (infer from tone)
- What they liked: bullet points
- What they want revised: numbered list
- Assessment: paragraph on how addressable their concerns are
- Risk: None / Low / Medium / High with explanation
Identify Cross-Cutting Themes — concerns that appear across 2+ reviewers, tagged T1, T2, etc.
Estimate Acceptance Probability with factors for/against
Bucket comments into Priority 1/2/3 response categories
List Vulnerabilities (weaknesses in the paper that reviewers exposed)
Populate the Publication Strategy section:
- Strategy A (minimal revision): venues that would accept the paper's strengths as-is, despite the weaknesses reviewers identified. Look for venues that value the descriptive/empirical contribution without demanding the specific improvements the current reviewers want.
- Strategy B (substantial revision): venues worth targeting if the authors invest effort to address the major reviewer concerns. These should be equal or higher prestige than the current venue.
- For conferences: check CORE rankings via .context/resources/venue-rankings.md (and the CSV at .context/resources/venue-rankings/core_2026.csv). Note upcoming deadlines.
- For journals: check CABS AJG rankings via .context/resources/venue-rankings.md (and the CSV at .context/resources/venue-rankings/abs_ajg_2024.csv). For SJR score, query the Elsevier Serial Title API (see venue-rankings.md for snippet; requires SCOPUS_API_KEY). Flag journals below CABS 3 only if there's a strong fit rationale.
- Recommendation table: rank 3-5 venues in priority order with rationale. First option should always be "revise for current venue" if acceptance probability is above ~30%.
- Key Decision: frame the core trade-off the authors face (e.g., speed vs. impact, minimal vs. substantial revision effort).
- Consider the paper's discipline and methodology when suggesting venues — a qualitative policy analysis fits different outlets than a computational study.
Leave Timeline empty (user fills)

Phase 7: Summary & Review

Present to the user:

Total comments extracted (by reviewer)
Breakdown by type and priority
Key cross-cutting themes
Any comments that were ambiguous or hard to classify
Ask for corrections before finalising

Critical Rules

Verbatim means verbatim. Never paraphrase reviewer text in the LaTeX transcription. Copy exactly.
Every comment gets an ID. No reviewer concern should be lost. If in doubt, give it its own ID.
Don't write actions. The Comment Matrix Action column stays blank — that's the user's job.
Don't overwrite. If files already exist at the target location, flag and version.
Compile the LaTeX. The verbatim document must build without errors before the skill completes.

Templates

Located in templates/referee-comments/:

comment-tracker.md
review-analysis.md
reviewer-comments-verbatim.tex

Cross-References

/proofread — for proofreading the response letter before submission
/bib-validate — run after revision to check bibliography
/pre-submission-report — full quality check before resubmission
paper-critic agent — for self-review of the revised paper

process-reviews