git:20261014.83fe1f8 to git:20261014.3ca5111

1 added, 1 removed. Audit A to A.

---

name: paper-reading

description: >-

Read an academic paper deeply and deliver one self-contained visual HTML reading document: global concept map, method or argument flow, mechanism explanations, experiment map, and synthesis. Use for PDF, arXiv, URL, or local papers when the user asks to read, understand, explain, visualize, compare, review, or build on a paper. Ordinary “read this paper” requests use a complete understanding-first read; reviewer critique and research planning are optional lenses.

---

# Paper Reading

Turn a paper into a navigable explanation that lets a reader move from the whole argument to its technical and experimental details. The default outcome is understanding the paper on its own terms. Scientific scrutiny stays present as source discipline; it becomes the organizing lens only when the user asks for review, credibility assessment, comparison, or research planning.

## Choose depth and lens

- **Default: DEEP READ.** “Read this paper,” “仔细读,” and requests for a mind map or diagram mean a complete read. Do not infer a critique-first objective or stop after a preliminary relevance judgment.

- **SCAN** only when the user asks for triage, a quick overview, or whether to read further. Stop after the overview only in this mode.

- **REVIEW lens** when the user asks whether conclusions hold, for weaknesses, or for a reviewer-style assessment. Add the [critique matrix](references/critique-matrix.md) after explaining the paper.

- **RESEARCH lens** when the user supplies an active research question or asks for comparison, reproduction, or next experiments. Add the [research card](references/research-card.md) and, when useful, the [evidence state](references/evidence-state.md).

Read [reading modes](references/reading-modes.md) only when depth or lens is ambiguous. Select the relevant [paper-type protocol](references/paper-types.md) for a theory, benchmark, dataset, survey, empirical, or systems paper.

## Build the reading atlas

Read the paper in passes: inspect the abstract, introduction, overview figures, conclusions, and main results for a provisional map; then read methods, experiments, captions, appendices, and definitions to correct and deepen that map. A provisional map is never the final answer in DEEP READ. Confirm the paper identity, version, and access to the sections needed for its central claims before promising a complete read. If only an abstract or truncated source is available, obtain the full source or tell the user what is missing; do not present a partial reading as a complete atlas.

Produce these layers in this reader-facing order inside **one continuous reading document**, adapting diagram type to the paper:

Choose the chapter order as an editorial decision while drafting. If paper section order, process chronology, and explanation order differ, keep them distinct in your reasoning and make diagrams convey the actual process. Do not add a default section explaining why the document uses its chapter order or comparing multiple orders; show the paper's substance directly. Label evaluation as evaluation, and place cross-cutting components with the operations they support. Keep navigation labels short enough to scan.

1. **Global map:** research problem, setting, prior limitation, main idea, contributions, and where evidence enters. Give a short orientation paragraph and a labeled concept map.

2. **Main path:** method, training/inference pipeline, proof dependency, dataset construction, or benchmark protocol. Show inputs, transformations, decisions, outputs, and feedback loops. Explain each non-obvious arrow. Reconstruct the reason for each central design choice: the constraint it addresses, the mechanism expected to help, and the cost or assumption it introduces. Discuss an alternative only when the paper supplies one or it is needed to explain the choice; label your reconstruction as an inference when the authors do not state it.

3. **Mechanism zoom:** unpack the few operations essential to understanding the contribution: definitions, formulas, objective, algorithm, data movement, assumptions, and a small concrete example when useful. Connect the operations back to the design reason and explain why the stated effect should follow. Distinguish the author's explanation from your interpretation.

4. **Experiment atlas:** map each major question to its setup, baseline/control, metric, result, and conclusion. Preserve the actual denominator, unit, evaluation setting, and source figure/table. For each central claim, connect the reported observation or proof to the narrower reading it supports; distinguish a whole-system comparison from an ablation. Explain what the reader should notice before discussing limitations.

5. **Synthesis:** explain the specific dependencies or tension that connect this paper's mechanism and evidence. State what its experiments show and the scope of that reading. Avoid a generic “what to remember” recap, repeated figure list, or commentary about the reading document itself. Keep minor source discrepancies near the relevant fact rather than making them the ending. Add a reviewer audit only if the chosen lens needs it.

For every diagram, use [visual-reading](references/visual-reading.md): one question per view, labeled relationships, selective detail, and source anchors. A diagram gives conceptual orientation; it does not replace explanations, equations, tables, or original figures. Do not flatten the paper into one giant graph or force a method flow onto a theory or survey paper.

After reconstructing the paper, decide whether an interactive workflow would help the reader trace a specific branch, state change, feedback loop, or component relationship that a static view cannot show as clearly. Name the reader action and the insight it reveals before choosing interaction. Use a static diagram, original figure, or table when the whole relationship is clearer at once. Make this choice from the paper and the reading task, not from a fixed quota or the availability of Archify; record the reason briefly in the Markdown audit source without adding a meta section to the reading page. See [visual-reading](references/visual-reading.md) for the selection and validation checks.

## Default deliverable

For DEEP READ, deliver **one self-contained HTML file** that a reader can follow from overview to details without opening separate diagram pages or returning to the paper for essential explanations. Put the overview, mechanism diagrams, readable original figure excerpts when useful, formulas, experiment data, worked examples, explanations, and source pointers in the same document. A source pointer is for verification, never the entire content of a card or section; hide PDF page and figure citations in the default HTML reading view and provide an explicit way to reveal them. The audit Markdown retains all references. Show the actual setup, baseline, observation, and interpretation beside each consequential experiment. Embed locally generated graphics and any Archify views into that file; separate JSON, Markdown, and diagram HTML are editable build inputs, not the primary reader-facing output. Keep a Markdown audit source alongside the HTML. For SCAN or when the user explicitly requests another format, match that request.

- A reusable renderer for this repository's examples is [render-reading.cjs](scripts/render-reading.cjs); use it when its Markdown/visual inputs fit the paper, or create an equivalent single-file HTML. Its build uses this repository's files and `package.json` dependencies only. Do not require a separately installed local skill, Archify CLI, or a machine-specific path. Pre-rendered interactive HTML may be embedded as an optional input. Do not turn the example's layout into a fixed template for every paper type. Before the first render in a fresh checkout, run `npm ci` in the skill directory (the renderer needs `marked` and `katex`) and optionally `npm run doctor` as a smoke build. Follow [renderer-format](references/renderer-format.md) for the exact input contract — fenced visual blocks and their JSON fields, citation patterns that hide with the source toggle, image formats and paths, math syntax, and the build errors that guard them. Name artifacts `examples/<slug>-deep-read.md` with assets in `examples/assets/`, rendered to `docs/<slug>-deep-read.html`; `npm run build:examples` renders every source, and [CONTRIBUTING.md](CONTRIBUTING.md) lists how a new reading is registered.

+ A reusable renderer for this repository's examples is [render-reading.cjs](scripts/render-reading.cjs); use it when its Markdown/visual inputs fit the paper, or create an equivalent single-file HTML. Its build uses this repository's files and `package.json` dependencies only. Do not require a separately installed local skill, Archify CLI, or a machine-specific path. Pre-rendered interactive HTML may be embedded as an optional input. Do not turn the example's layout into a fixed template for every paper type. Before the first render in a fresh checkout, run `npm ci` in the skill directory (the renderer needs `marked` and `katex`) and optionally `npm run doctor` as a smoke build. Follow [renderer-format](references/renderer-format.md) for the exact input contract — fenced visual blocks and their JSON fields, citation patterns that hide with the source toggle, image formats and paths, math syntax, and the build errors that guard them. For an ordinary reading, write the deliverable into a dedicated directory of the user's own project (for example `paper-readings/<slug>/`), with the audit source and its `assets/` co-located; any output path is fine. Invoke the renderer from the installed skill path (`node <skill-dir>/scripts/render-reading.cjs <source>.md <output>.html`), which works with sources and outputs outside the skill directory. The `examples/<slug>-deep-read.md` + `docs/<slug>-deep-read.html` convention applies only when contributing to this repository's public gallery; [CONTRIBUTING.md](CONTRIBUTING.md) lists how those are registered.

Choose the reading language before drafting: follow an explicit user preference; otherwise use the language of the user's request, and use English when the request gives no language cue. The paper's own language does not override the reader's language. If a mixed-language request leaves the intended output genuinely unclear, ask once. Keep headings, diagrams, captions, alt text, tables, and navigation in the chosen language; retain necessary technical names and original quotations. Declare that choice on the first line of every Markdown audit source with `` or ``. The bundled renderer requires this marker and sets the HTML `lang` and interface labels from it. For another requested language, use an equivalent HTML build with the correct `lang` and localized interface instead of silently switching languages. Name the output language in the delivery message and label the language of published examples.

Choose a paper-appropriate visual theme without changing the evidence or reading structure. The bundled renderer offers `forest`, `cobalt`, `plum`, and `saffron`; add an optional second source line such as ``. It uses `forest` when that line is absent. The choice is editorial, not automatic content detection. Keep heading, card, and diagram titles free of terminal sentence punctuation in both languages unless punctuation is part of a quoted title or notation.

## Evidence and rendering contract

- Tie important facts, nodes, arrows, formulas, and numbers to exact PDF page/section/figure/table/appendix references in the audit source. Keep those references retrievable in the HTML without showing them by default. In a PDF, verify captions and table cells visually when extraction is uncertain; when chart labels or bar-to-category mappings are ambiguous in the text layer, use the coordinate verification in [figure-extraction](references/figure-extraction.md) and record conflicting readings instead of guessing. Record source version and conflicting numbers instead of silently resolving them.

- If prose invokes an equation to explain a mechanism, render the full relevant equation beside that explanation, preserve its denominator and masks, and define the variables readers need. Distinguish an algebraically equivalent screen layout from a different objective. If a chart uses values from a paper figure, visibly label it as a redraw or approximation and name the source panel; visibly label embedded original figures as original. Figure identifiers remain readable even when page-number references are hidden.

- Introduce every embedded original figure in visible prose before the image: say what question it answers, which panel, axis, or arrow to inspect, and what the reader should learn from it. The figure caption may add provenance and a short reminder, but must not be the only explanation. Crop figure regions from the PDF with the recipe in [figure-extraction](references/figure-extraction.md), keeping the paper's figure number in the filename. Check all embedded figures for orphaned images after rendering, including figures referenced only inside hidden PDF citations.

- Mark **paper statement**, **observed result**, and **reader inference** distinctly. End-to-end comparisons describe system results; controlled ablations can isolate a mechanism. Do not automatically make claim auditing the reader's objective.

- Use a readable Markdown source as the portable audit copy. Derive HTML content from that source and structured figure data; keep figures, numbers, equations, and qualifiers aligned. Important content must remain readable without scripts and offline. Render math as math, not code text.

- Give the first screen paper-specific orientation rather than decorative shapes or generic slogans. For before/after results, show both values on a shared scale, label the metric and unit, and keep the numerical table. Render inline formulas as part of their sentences, with following punctuation in the same inline unit; reserve separate blocks for display formulas. Bundle the math stylesheet and fonts into offline HTML, and retain accessible math semantics. Inspect the final HTML for broken Markdown markers, isolated inline formulas, overflow, and figures whose caption only points elsewhere.

- An editorial overview graphic can borrow the clear hierarchy of the project homepage preview: a paper-specific question, a compact mechanism view, and an evidence view in a shared visual language. Replace its content with paper-specific relationships and verified numbers. Static graphics must not imitate chapter navigation or clickable controls. Label illustrative paths and schematic bars as such; never let a decorative bar imply a measured result. Introduce the view in prose and explain the important arrows and quantities nearby.

- When interaction is justified, embed the working view inside the final HTML as a supplementary exploration view. Use Archify if it fits and is available, or build the view with self-contained HTML/SVG and local script when needed; the reading skill must not depend on Archify or another installed skill. Keep the main path, every consequential branch, and its learning signal or result readable in visible prose or static graphics without scripts. Preserve source inputs and links to paper evidence. See [visual-reading](references/visual-reading.md).

- Before delivery, apply the [reading quality gates](evals/reading-quality.md) to the source, Markdown audit copy, and final HTML. Repair failed gates before presenting a DEEP READ. The public [reader tasks](evals/reader-tasks.md) illustrate how to test whether a person can reconstruct a paper using only the HTML; passing a renderer test is not evidence of reader comprehension.

- The response should let a reader answer: What is the whole paper about? How does its central mechanism work? Which experiments test which questions? What do the results actually say? What remains uncertain?