/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:

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 — Triag