Paper Deep Reader

Paper Deep Reader

Overview

Read one or several papers as evidence, not as abstracts to paraphrase. First determine what kind of intellectual object the paper is. Then reconstruct it using the right lens: an empirical paper needs methods and experiments; a theory paper needs definitions, assumptions, derivation, and implications; a position paper needs thesis, argument chain, examples, objections, and evidential limits. Translate that reconstruction into an explanation optimized for understanding and reuse.

The default answer is Chinese with English technical terms retained on first mention. The default artifact is an inline Markdown answer. Create a Markdown note only when requested or when the task explicitly asks for a reusable artifact.

The skill has two separate layers:

Evidence layer: paper text, figures, equations, tables, appendix, code
Explanation layer: conclusion → mental-model correction when needed → paper-native structure
                   → example/derivation/evidence as appropriate → limitations → summary

The explanation layer must never outrun the evidence layer.

When to Use

Use for:

• “读/拆解/精读/总结/解释这篇论文”；
• a PDF, arXiv link or ID, DOI, title, or pasted paper text;
• questions about a paper's method, figure, equation, dataset, experiments, novelty, limitations, cost, or reproducibility;
• comparison or synthesis of multiple papers;
• deciding how a paper fits the user's own system or research direction.

Do not use as the primary workflow for field-wide discovery, simple bibliographic search, document extraction with no analysis, or manuscript writing. If the client provides separate PDF, scholarly-search, or research-landscape capabilities, use them as supporting tools without making this skill depend on their names.

Non-negotiable Rules

1. Read fresh. Do not analyze from memory or abstract alone when the full paper is accessible.
2. Version-lock. Record the exact PDF/version/date inspected. Preserve an arXiv version suffix when available.
3. No invented detail. Never manufacture scores, dimensions, dataset sizes, hardware, costs, baselines, citations, or implementation choices.
4. Separate provenance. Mark material as 论文事实, Agent推断, or Agent判断 whenever the boundary could be unclear.
5. Trace claims to evidence. Important technical and numerical claims need a section, figure, table, equation, appendix, or page locator.
6. Correct before expanding. If the user's wording implies a wrong mental model, correct it briefly before explaining the rest.
7. Clarify relationships. State whether listed items are parts of one system, sequential stages, alternative methods, parallel resources, or evaluation views.
8. One sample end to end. For abstract pipelines, walk one concrete input through every major stage.
9. Numbers need denominators. Report scale with units and context, not isolated large numbers.
10. Do not call a pipeline an Agent unless it has goal-directed multi-step behavior, state, tools/environment interaction, or feedback-driven execution.
11. Genre before template. Never force a conceptual, theoretical, survey, qualitative, or position paper into an empirical ML template.
12. No empty-section theater. Omit dimensions that are not meaningful for this paper instead of repeatedly saying “not applicable.”
13. User relevance is opt-in. Connect the paper to the user's project only when asked, clearly useful, or already part of the reading contract; do not append a domain adaptation section by default.
14. Adaptive explanation. Trees, tables, equations, and examples are tools, not mandatory slots. Use only the representation that reduces confusion.

Workflow

1. Resolve the reading contract

Infer the likely goal from the request. Do not block on clarification when a sensible default exists.

Default depth:

| Request | Reading depth | Default output | |---|---|---| | “这篇讲什么” | focused | thesis, structure, one sample, evidence, limits | | “详细拆解/精读” | deep | full framework in this skill | | asks one module/equation/table | targeted | local answer plus enough system context to prevent misunderstanding | | several papers | comparative | per-paper identity cards plus normalized comparison | | “能否复现/怎么用于我的项目” | implementation | dependencies, data, resources, gaps, adaptation plan |

If the audience is unspecified, explain for a technically capable reader who is new to this exact method. Define specialist terms at first use but do not reteach generic fundamentals unless needed.

Completion criterion: input scope, paper count, and intended answer depth are known or safely defaulted.

2. Classify the paper before choosing an analysis frame

Classify by primary contribution, not by venue label or the presence of a few equations/tables. A paper may have secondary traits; choose one primary type and optionally one secondary type.

| Primary type | Diagnostic question | Core analysis dimensions | |---|---|---| | Empirical method/system | Does it propose or evaluate an implemented method or system? | task, inputs/outputs, method, data, protocol, baselines, results, ablations, cost | | Dataset/benchmark | Is the main contribution a corpus, benchmark, annotation scheme, or evaluation protocol? | scope, unit, provenance, annotation, splits, leakage, metrics, coverage, license | | Theoretical/formal | Is the main contribution a theorem, formal model, proof, bound, or derivation? | definitions, assumptions, statement, proof strategy, dependencies, examples, scope | | Position/conceptual | Is it primarily arguing for a thesis or research agenda? | thesis, argument chain, premises, cases/analogies, objections, support type, implications | | Survey/tutorial | Is it organizing or teaching an existing field? | scope, taxonomy, selection method, synthesis, consensus, omissions, usefulness | | Qualitative/case study | Is evidence mainly interviews, observations, documents, or one/few cases? | research question, context, sampling, coding/interpretation, evidence excerpts, transfer limits | | Review/meta-analysis | Does it systematically aggregate prior studies? | protocol, inclusion/exclusion, quality assessment, effect synthesis, heterogeneity, bias | | Resource/tool/protocol | Is the contribution software, instrumentation, workflow, or protocol? | use case, interface, dependencies, validation, usability, limitations, maintenance |

If classification is ambiguous, write a one-line hybrid label such as position paper with a historical case study or method paper plus benchmark contribution. Do not ask the user unless choosing the wrong frame would materially change the answer.

Completion criterion: primary type, secondary type if any, and the matching analysis dimensions are explicit internally before detailed reading.

3. Acquire and verify the source

Use this source order:

1. user-provided local PDF;
2. official publisher/proceedings or author PDF;
3. versioned arXiv HTML/PDF;
4. repository manuscript;
5. pasted text.

For a local PDF:

• inspect metadata and page count;
• use lightweight text extraction for text PDFs;
• use advanced OCR only for scans, equations, or broken layout;
• inspect figures/tables visually when text extraction loses spatial meaning.

For a URL or identifier:

• fetch metadata and full text;
• resolve title, authors, date, version, venue/status, and links;
• distinguish preprint, workshop, conference, journal, and withdrawn/retracted status.

If only a title is provided, search for the primary source. Ask for help only when multiple papers remain genuinely ambiguous or the source is inaccessible.

Completion criterion: the actual full text or the best available primary source has been inspected, and any source limitation is disclosed.

4. Build a genre-aware paper map before explaining

Read in two passes.

Pass A, orientation: title, abstract, introduction, section headings, conclusion, main figures, main result tables.

Pass B, verification: method, equations, datasets, implementation details, experiments, ablations, limitations, appendix, code/repository if relevant.

Construct a universal core map:

Paper
├── Identity: version, venue/status, task type
├── Question/problem: what gap or puzzle motivates the paper
├── Contribution: what intellectual work the paper claims to add
├── Reasoning object: model, theorem, argument, taxonomy, dataset, cases, or protocol
├── Support: experiments, proof, citations, examples, cases, synthesis, or expert reasoning
├── Alternatives: baselines, rival explanations, prior frameworks, objections, or null hypothesis
└── Boundaries: assumptions, scope, uncertainty, missing tests, and limitations

Then add only the type-specific branch:

Empirical       → data → method → evaluation protocol → results → failure analysis
Dataset         → provenance → schema/annotation → splits → coverage/leakage → benchmark use
Theory          → definitions → assumptions → statement → derivation/proof → consequences
Position        → thesis → premises → argument steps → cases/analogies → objections → agenda
Survey          → scope → selection → taxonomy → synthesis → omissions
Qualitative     → context → sampling → analysis method → evidence themes → transferability
Meta-analysis   → search protocol → eligibility → study quality → synthesis → heterogeneity/bias
Resource/tool   → use case → interface/workflow → dependencies → validation → operational limits

Do not mirror the paper's section order in the final explanation unless that order is genuinely clearer. Do not create empirical headings for a position paper just to mark them absent.

Completion criterion: every branch above is filled, marked absent, or marked not reported.

5. Create a claim-support ledger

Keep a compact ledger while reading. Support is deliberately broader than experimental evidence:

| ID | Claim | Source locator | Support type | What it supports | Confidence | |---|---|---|---|---|---| | E1 | dataset contains N samples | Sec. 4.1 / Table 1 | measurement/report | dataset scale | high | | E2 | theorem holds under assumptions A–C | Theorem 1 / proof | formal proof | theorem validity in scope | high | | E3 | theory X cannot explain case Y | Sec. 3 / historical case | case/argument | critique of X, not universal impossibility | medium | | E4 | component C likely drives the gain | Table 4 | Agent inference from ablation | causal interpretation | medium |

Preferred locators: Table 2, Fig. 3, Eq. (4), Appendix B, then PDF page. Page alone is weaker because versions differ.

When figure and prose disagree, report the discrepancy. When an exact fact is not reported, write 未报告, not an estimate. If an estimate is useful, show its assumptions and label it.

Support types include measurement, controlled experiment, formal proof, derivation, citation synthesis, historical case, qualitative excerpt, worked example, analogy, expert argument, author assertion, Agent inference, and Agent judgment.

For argument-driven papers, reconstruct premise → inference → conclusion and state whether each step is entailed, plausible, illustrative, or merely asserted. A case study may refute a universal claim or illustrate possibility, but it rarely establishes universal frequency or impossibility by itself.

Completion criterion: every headline claim and number has a locator, support type, and calibrated statement of what that support can and cannot establish.

6. Reconstruct the paper's central object

Use the branch matching the paper type.

For implemented methods, systems, and tools

First identify the relationship type:

| Relationship | Meaning | Preferred wording | |---|---|---| | whole/part | modules belong to one system | “A、B 是同一模型的两个子模块” | | sequence | output of one stage feeds the next | “A → B → C 是处理顺序” | | alternatives | methods solve the same role differently | “A、B 是二选一的方案” | | parallel resources | independent evidence/data stores | “A、B 是并行资源，不是同一库的层级” | | evaluation views | same output measured differently | “这些是同一结果的不同评价维度” |

Then reconstruct:

1. What is one input unit?
2. What fields/tensors/objects exist at entry?
3. Which component transforms each object?
4. What is learned, retrieved, frozen, generated, or manually supplied?
5. What changes during training?
6. What happens at inference?
7. What exact output is produced?
8. Which loss or rule connects the output to supervision?

For equations, use this order:

plain-language purpose
→ one concrete numeric/shape example
→ equation
→ symbol table
→ operational interpretation
→ assumptions and edge cases

Never present a symbol before saying what problem the equation solves. Do not rename dot products as cosine similarity, scores as probabilities, or correlation as causation unless the paper establishes it.

Completion criterion: one input can be traced end to end without an unexplained jump.

For theoretical and formal papers

Reconstruct in this order:

problem setting → definitions → assumptions → main statement
→ proof/derivation strategy → worked example or boundary case → implications

Distinguish a definition from an assumption, a theorem from an interpretation, and proof validity from real-world applicability. Explain equations only when central; define every symbol used.

For position and conceptual papers

Reconstruct the argument rather than inventing a “method pipeline”:

thesis
├── premise 1 + support
├── premise 2 + support
├── inference connecting premises to thesis
├── central case, analogy, or thought experiment
├── rival account or objection
└── proposed research agenda / consequence

For each major step, ask:

1. Is it descriptive, normative, causal, possibility, or impossibility language?
2. Is support direct evidence, cited evidence, a historical case, analogy, or author assertion?
3. Does the conclusion follow, or is an additional premise required?
4. What would falsify or weaken the thesis?

For surveys, qualitative studies, datasets, and reviews

Follow the type-specific branch from Step 4. Explain the selection/sampling process and coverage boundary before summarizing conclusions. The reader must know what universe the paper's synthesis can legitimately represent.

7. Audit evidence using the genre-appropriate protocol

Run this section only for dimensions meaningful to the paper. For an empirical or dataset paper, use the detailed checks below. For other genres, use the corresponding checklist after them.

Empirical data

Report:

• source and collection process;
• unit of observation;
• modalities and fields;
• labels, pair cardinality, or annotation process;
• raw vs augmented/synthetic counts;
• class/domain distribution;
• train/validation/test split;
• split timing relative to augmentation;
• duplicate, subject/site/source-instance leakage risks;
• release/license status if relevant.

For image-text datasets, separate:

1. pair existence;
2. one-to-one vs one-to-many cardinality;
3. class consistency;
4. instance-level factual grounding.

Empirical experiments

Normalize evidence into:

| Question | Required evidence | |---|---| | Does it outperform alternatives? | matched baselines, same split/protocol, main metrics | | Which component matters? | ablation with exact deltas | | Does it generalize? | cross-domain/external/temporal evaluation | | Is it robust? | corruptions, subgroups, failure cases, uncertainty | | Is it practical? | latency, memory, compute, data/annotation cost | | Is it reproducible? | code, seeds, configs, hardware, variance |

Distinguish best single score, average across tasks, relative improvement, and absolute percentage-point gain. Never convert among them silently.

Other evidence protocols

| Paper type | Evidence audit | |---|---| | Theory/formal | assumptions explicit; proof c

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: xtnntn
• Source: xtnntn/paper-deep-reader
• License: MIT

Install and usage instructions live in the source repository linked above.