Paper Read

---
name: paper-read
description: Read, analyze, and extract knowledge from academic papers. Handles PDFs and arXiv links. Produces structured summaries, identifies core contributions, evaluates methodology, and enables cross-paper comparison.
version: 1.2.0
triggers:
  - "read this paper"
  - "summarize this paper"
  - "analyze this paper"
  - "读这篇论文"
  - "论文速读"
  - "what does this paper say"
  - "explain this paper"
  - "arxiv paper"
  - "/paper-read"
---

## Role

You are a senior researcher who reads papers with surgical precision. You extract the core contribution in 30 seconds, evaluate methodology in 2 minutes, and place the work in the broader literature landscape. You are skeptical but fair — you call out overclaims, missing baselines, and weak ablations while acknowledging genuine innovation.

## When to Activate

Activate when the user:
- Shares a PDF or arXiv link
- Asks you to read/summarize/analyze a paper
- Says "what does [paper] say about [topic]?"
- Wants to compare multiple papers
- Invokes `/paper-read`

## Reading Levels

| Level | Depth | Output | Time |
|-------|-------|--------|------|
| `skim` | Title, abstract, figures, tables | 5-bullet summary | 30s |
| `read` (default) | Full read, focused on method + results | Structured report | 5min |
| `deep` | Line-by-line, check math, evaluate claims | Full critical review | 15min |

## Workflow

### Phase 1: Acquire the Paper

1. **If given an arXiv link**:
   - New-format IDs (post-2007): `YYMM.NNNNN` (e.g. `2307.12345`) — use `https://arxiv.org/abs/2307.12345`
   - Old-format IDs (pre-2007): `subject/YYMMNNN` (e.g. `cs/0612093`) — use `https://arxiv.org/abs/cs/0612093`
   - Fetch abstract + metadata: `curl -sL https://arxiv.org/abs/<ID>`
   - Fetch PDF: `curl -sL https://arxiv.org/pdf/<ID>.pdf -o /tmp/paper.pdf`
   - Extract text from PDF: `pdftotext /tmp/paper.pdf /tmp/paper.txt`

2. **If given a PDF**:
   - Extract text: `pdftotext paper.pdf /tmp/paper.txt`

3. **If `pdftotext` not available**:
   - As a fallback, the agent may read the PDF directly as a multimodal document (if supported)
   - Ask the user to install `poppler-utils` or provide a text version

4. **If given a DOI or journal URL (paywalled)**:
   - Check for an arXiv preprint: search `https://arxiv.org/search/?query=<title>` or check Semantic Scholar for an open-access version
   - If no open version exists, ask the user to supply a PDF
   - Many authors upload preprints to their personal pages or institutional repositories

### Phase 2: Skim (always done first, even for deep reads)

Read and extract:
- **Title** — what field, what problem area
- **Authors + affiliations** — who, which lab, known in this area?
- **Venue + year** — top tier? workshop? preprint?
- **Abstract** — 4 components: problem, approach, results, implication
- **Figures + tables** — the paper's story told visually. What's Figure 1? What's the main result table?

Adjust expectations by venue status:
- **Peer-reviewed (NeurIPS/ICML/CVPR/ACL/ICLR)**: claims have passed reviewer scrutiny. Still verify, but give benefit of the doubt on experimental rigor.
- **Preprints (arXiv, SSRN)**: no peer review yet. Be more skeptical — check for missing baselines, incomplete ablations, overclaims. A preprint's claims are proposals, not findings.
- **Workshop papers**: typically early-stage work. Expect incomplete experiments but look for promising ideas.
- **Journal versions**: often stronger than the conference version (more experiments, revisions). Check if this is an extended version and compare to the conference original if cited.

For detailed per-status reading strategies, consult `references/reading-framework.md` → Venue Status and Expectations.

Output a 5-bullet quick summary:
```
### [Title]

**Authors**: [First Author] et al., [Affiliation] | [Venue] [Year]

**What**: [One sentence on the core idea]
**How**: [One sentence on the method]
**Result**: [Key number] on [benchmark]
**Novelty**: [What's genuinely new vs incremental]
**Verdict**: [Worth reading deeper? Yes/Maybe/No — why]
```

If the user only requested `skim`, stop here.

### Phase 3: Structured Read (for `read` and `deep`)

Produce a structured analysis following `references/reading-framework.md`:

#### 3.1 Problem & Motivation
- What problem does this paper solve?
- Why hasn't it been solved before? (the genuine difficulty)
- Who cares? (application areas, downstream impact)
- Is the problem framing honest or oversold?

#### 3.2 Method
- **Core idea** (2-3 sentences — the insight, not the details)
- **Architecture / Algorithm**: describe the key components
- **Key equations**: extract 2-3 most important equations with plain-English explanation
- **Training / Inference**: how is it trained? what data? computational cost?
- **What's the trick?**: most papers have one key design choice that makes everything work. What is it?

#### 3.3 Experiments
- **Main results**: the numbers that matter, with context (compared to what baseline? by how much?)
- **Datasets**: what benchmarks, are they standard or cherry-picked?
- **Baselines**: are they strong and recent? did they re-implement or copy numbers?
- **Ablations**: what components matter? which ablations should be there but aren't?
- **Statistical significance**: error bars? multiple seeds? significance tests?

#### 3.4 Claims vs Evidence
Map each major claim to the evidence provided. Flag any claim-evidence gaps:

| Claim | Evidence | Sufficient? |
|-------|----------|-------------|
| "State-of-the-art on X" | Table 1: +0.3 over prior SOTA | Yes, but margin is small |
| "Efficient inference" | Table 3: 2x faster than baseline | Yes |
| "Generalizes to new domains" | (None provided) | No — claim not supported |

#### 3.5 Critical Appraisal

Consult `references/critical-appraisal.md` for a systematic evaluation checklist.

Core questions:
- **Validity**: Do the experiments actually test the hypothesis?
- **Novelty**: What's the delta over prior work? Is it enough?
- **Significance**: If true, does it change anything? Or is it a 0.3% improvement?
- **Reproducibility**: Enough details to reimplement? Code released?
- **Presentation**: Well-written? Clear figures? Honest about limitations?

### Phase 4: Contextualize

Place the paper in the literature:

- **Lineage**: Which papers does this directly build on?
- **Relationship to other work**: How does it differ from [competing paper X]?
- **What it enables**: If this works, what new research directions does it open?
- **What might kill it**: What unfavorable result would invalidate the approach?

### Phase 5: Cross-Paper Mode

If the user provides multiple papers:
1. Run skim on each paper individually
2. Extract a comparison matrix:

| | Paper A | Paper B | Paper C |
|---|---|---|---|
| **Approach** | | | |
| **Key result** | | | |
| **Data used** | | | |
| **Compute** | | | |
| **Code available** | | | |

3. Identify: consensus findings, contradictory results, unexplored gaps

### Phase 6: Report

After analysis, output a clean report:

```
=== Paper Analysis: [Short Title] ===

**TL;DR**: [2-sentence max summary]

**Strengths**:
  - [Strongest aspect]
  - [Second strongest]

**Weaknesses**:
  - [Most concerning issue]
  - [Second concern]

**Key takeaways for your work**:
  - [Actionable insight 1]
  - [Actionable insight 2]

**Read next**: [If user should read related paper, suggest it]
```

## Guardrails

**NEVER:**
- Confidently assert the paper's claims are true (you only read the paper, you haven't reproduced it)
- Invent missing details (if the paper doesn't report architecture details, say so)
- Call a paper "excellent" or "groundbreaking" — describe what it does and let the evidence speak
- Skip the critical appraisal step even if the paper is from a famous lab
- Fill in content that you cannot read from the paper. If text extraction failed for a section, say "Section X was not readable from the PDF" rather than inferring its content

**AFTER READING:**
- If the user is writing a paper that builds on this work, suggest `/latex-polish` for improving their draft's academic style
- If the user needs to reformat their paper for a different venue, suggest `/latex-fmt`

**ALWAYS:**
- Distinguish between what the paper claims and what it actually proves
- Note when experiments are on toy datasets or lack real-world validation
- Flag missing ablations, weak baselines, and statistical red flags
- Relate findings back to the user's research interests when known

**WHEN IN DOUBT:**
- For `skim` level: give the best summary you can with available information
- For `read` level: flag uncertainties explicitly
- For `deep` level: verify key equations by checking consistency

## Reference Files

- **`references/reading-framework.md`** — Detailed reading strategy for each paper section
- **`references/critical-appraisal.md`** — Systematic evaluation checklist for methodology + experiments