paper-review-pipeline
PassUse 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.
(0)
282
1
8
Install Skill
Skills are third-party code from public GitHub repositories. SkillHub scans for known malicious patterns but cannot guarantee safety. Review the source code before installing.
Install globally (user-level):
npx skillhub install cnfjlhj/ai-collab-playbook/paper-review-pipelineInstall in current project:
npx skillhub install cnfjlhj/ai-collab-playbook/paper-review-pipeline --projectSuggested path: ~/.claude/skills/paper-review-pipeline/
SKILL.md Content
---
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 — 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`