paper-review-pipeline

name: paper-review-pipeline description: Use when a mostly complete ML conference paper needs self-review, pre-submission QA, camera-ready checking, section-by-section critique, citation-risk inspection, or rebuttal/review-response drafting. Skip this for initial drafting and use `paperreview` only when the user explicitly wants external submission.

Paper Review Pipeline (ML Top Conferences)

Run a two-view paper review for ML conference submissions:

Section-by-section review (Abstract → Intro → Method → Experiments → …) with concrete edits.
Prioritized issue list with P0/P1/P2 severity, grouped by category, including recommended fixes and verification notes.

This skill also supports rebuttal / review response: parse reviewer comments, classify, choose a strategy, and draft a professional point-by-point response.

Parity Guarantee (No-Omission)

This skill is a consolidation layer. It must not omit any distinctive workflow, constraints, or output formats from the legacy skills it replaces.

Use:

references/parity-matrix.md as the feature-parity contract and regression scenarios.
references/modules/ for full imported workflows and checklists.

Execution Modes

This skill supports two modes:

Default: targeted — run only the most relevant tracks based on the user request and inputs, but always produce the Final Synthesis.
Optional: full-parallel — run all tracks as independent outputs (acceptable redundancy), then produce the Final Synthesis.

Trigger full-parallel when the user says: “全量”, “并行”, “run all tracks”, “run every skill”, “逐个 skill 测试”, “full pipeline”.

Protocol + required report template:

references/full-parallel-protocol.md
references/report-template.md

Optional External Second Opinion (`paperreview`)

If the user provides a near-final or final PDF, complete the local review first and then explicitly ask whether they also want an external second opinion via paperreview.

Ask only when the input is clearly a near-final or final PDF.
Do not auto-submit to external services. Get explicit confirmation first.
If the user agrees, hand off to paperreview as a follow-up step; otherwise finish with the local pipeline result only.

When to Use

Pre-submission quality check (ICML/ICLR/NeurIPS/AAAI).
After a draft is “mostly done” but clarity/logic is shaky.
When you suspect citation problems (missing, inconsistent, unverified, or claim-to-citation mismatch).
Before sending to advisor/collaborators for feedback (to reduce “obvious issues”).
After receiving reviews: draft rebuttal and a revision plan.

When NOT to Use

If the user wants new research or new experiments invented: require the user to provide results/artifacts.
If the user asks for verbatim PDF-to-LaTeX copying or large-scale reformatting without source.
If the task is pure BibTeX generation from memory: do not do it; use verified metadata workflows.

Non-Negotiable Guardrails

No hallucinated citations.
- If a citation cannot be verified, mark it as [CITATION NEEDED] / placeholder and tell the user explicitly.
- Do not fabricate authors/years/venues/DOIs.
Do not change technical meaning.
- When proposing edits, preserve claims and numbers unless the user provides corrected data.
Preserve LaTeX semantics when editing source.
- Do not break \\cite{}, \\ref{}, \\label{}, math environments, figures/tables, or bibliography hooks.
Respect blind review constraints (if applicable).
- Avoid identity-revealing self-citations, acknowledgments, or repo links unless the user confirms it is camera-ready.

Inputs (Ask for the Minimum Needed)

For pre-submission review

Paper source: LaTeX section text, or the relevant excerpts pasted in chat (preferred), and optionally the PDF for context.
Target venue + track (ICML/ICLR/NeurIPS/AAAI) and any required sections (e.g., limitations / broader impact / ethics).
One-sentence contribution (if the user has it). If not, infer and ask for confirmation.

For rebuttal / review response

Reviewer comments (verbatim text, ideally grouped by reviewer).
Rebuttal constraints: word/page limit, formatting (ICLR OpenReview vs PDF), and timeline.
What the user is willing to change: “clarify only” vs “add experiments” vs “major rewrite”.

Output Contract (Always Produce Both Views)

View A — Section-by-Section Review

For each section, output:

What works (1–3 bullets)
What’s missing / unclear (P0/P1/P2 tagged bullets)
Concrete fixes (rewrite suggestions or structural moves)

Use the checklists in:

references/section-review-checklist.md

View B — P0/P1/P2 Issue List (Prioritized)

Format each issue like:

Priority: P0 (blocking) / P1 (important) / P2 (nice-to-have)
Category: Narrative / Evidence / Experimental Design / Statistics / Reproducibility / Citations / Writing / Figures-Tables / Format
Where: section name + a short quote anchor (or LaTeX label if available)
Problem
Fix
Verification (if needed): what evidence/log/search is required before claiming it is correct

Use the taxonomy in:

references/p0-p2-taxonomy.md

Modules (Routing Rules)

Use these modules to preserve legacy feature parity:

Paper-level QA: references/modules/paper-self-review.md
Rebuttal / review response: references/modules/review-response.md and references/rebuttal-workflow.md
LaTeX + BibTeX toolbox: references/modules/academic-paper-helper.md
Claim-level citation audit: references/modules/citation-validator.md and references/citation-integrity.md
Anti-AI polish: references/modules/writing-anti-ai.md
LaTeX rhythm pass: references/modules/latex-rhythm-refiner.md
Literature discovery (extended): references/modules/claude-scholar-ml-paper-writing.md

Workflow (Default)

Pass 0 — Triage (5–10 minutes)

Identify the one-sentence contribution and confirm it with the user.
Extract the top 3–7 claims the paper relies on.
For each claim, note the current support:
- empirical result (table/figure)
- theorem/proof
- citation / prior work
- ablation / analysis
Flag immediate P0 risks (typical: missing baselines, unclear experimental protocol, unverified citations, paper “about X” but experiments test Y).

Pass 1 — Section Review (primary deliverable)

Review sections in order (and check alignment between them):

Abstract
Introduction (motivation → gap → contribution bullets)
Related Work (positioning + not a bibliography dump)
Method (reproducible description + design justification)
Experiments / Results (fair baselines + full setup + statistical reporting)
Analysis / Ablations (claim-driven, not exploratory noise)
Limitations / Broader Impact / Ethics (venue-dependent)
Conclusion (tight restatement + constraints + future work without overclaim)

Pass 2 — Consolidate into P0/P1/P2

Turn findings into an actionable issue list:

P0 first (blockers / likely desk-reject causes)
P1 next (acceptance probability movers)
P2 last (polish)

Pass 3 (Optional) — Revision Plan

If the user wants an execution plan, produce:

3–8 tasks with measurable acceptance criteria
suggested order (dependency-aware)
what can be done in parallel (writing vs experiments vs citations)

Full-Parallel Workflow (Comprehensive)

When mode is full-parallel, do not collapse everything into one voice. Instead:

Run all tracks (A–G) as independent “mini-reviewers” and keep each track output visible.
Then produce the Final Synthesis:
- View A: consolidated section-by-section review
- View B: consolidated P0/P1/P2 issue list
- minimal revision plan
- conflicts & resolutions between tracks

Use:

references/full-parallel-protocol.md
references/report-template.md

Rebuttal / Review Response Module

When reviews arrive, do:

Parse and classify each comment: Major / Minor / Clarification / Missing baseline / Missing experiment / Writing / Citation / Misunderstanding.
Choose a strategy per item: Accept + change, Clarify, Defend, Add experiment, Defer (explain constraints).
Draft point-by-point responses with:
- gratitude + precise restatement
- what changed (or why not)
- where to find it (section/figure/table)
- evidence-based tone (no overpromising)