paper-review-pipeline

# Paper Review Pipeline (ML Top Conferences)

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

1) **Section-by-section review** (Abstract → Intro → Method → Experiments → …) with concrete edits.
2) **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

1) **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.
2) **Do not change technical meaning.**
   - When proposing edits, preserve claims and numbers unless the user provides corrected data.
3) **Preserve LaTeX semantics when editing source.**
   - Do not break `\\cite{}`, `\\ref{}`, `\\label{}`, math environments, figures/tables, or bibliography hooks.
4) **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)

1) Identify the **one-sentence contribution** and confirm it with the user.
2) Extract the **top 3–7 claims** the paper relies on.
3) For each claim, note the current support:
   - empirical result (table/figure)
   - theorem/proof
   - citation / prior work
   - ablation / analysis
4) 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):
1) Abstract
2) Introduction (motivation → gap → contribution bullets)
3) Related Work (positioning + not a bibliography dump)
4) Method (reproducible description + design justification)
5) Experiments / Results (fair baselines + full setup + statistical reporting)
6) Analysis / Ablations (claim-driven, not exploratory noise)
7) Limitations / Broader Impact / Ethics (venue-dependent)
8) 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:

1) Run all tracks (A–G) as independent “mini-reviewers” and keep each track output visible.
2) 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:
1) Parse and classify each comment: **Major / Minor / Clarification / Missing baseline / Missing experiment / Writing / Citation / Misunderstanding**.
2) Choose a strategy per item: **Accept + change**, **Clarify**, **Defend**, **Add experiment**, **Defer (explain constraints)**.
3) 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)

Use:
- `references/rebuttal-workflow.md`

## Citation Integrity Module (Hard Requirement)

Before submission, ensure:
- every non-trivial factual claim has a citation or empirical evidence
- every citation key resolves in the bibliography
- any newly added citations are verified (paper exists; BibTeX not fabricated)

If deep citation audit is requested, follow:
- `references/citation-integrity.md`