nature-reader

nature-reader builds full-paper, Chinese-English side-by-side, figure- and table-aware, source-grounded Markdown readers for journal or conference papers from PDF, DOI, arXiv, publisher HTML, or pasted text. It is triggered whenever a user asks to translate or read a paper, make bilingual side-by-side or full-text readings, extract figures or tables into their correct positions, preserve figure and table placement near the relevant prose, or keep exact source anchors for every block. It also responds to general paper-reading and translation requests, including Chinese phrasings, even without the word Nature, and must not degrade into summary-only output unless the user explicitly asks for a summary.

The skill is structured as a router split into two layers. A static layer under static/ holds versioned, reusable content fragments covering core principles, the reading workflow, the output contract, and per-source-format extraction guidance. A dynamic layer, consisting of this router file plus manifest.yaml, detects the request's source format and loads only the fragments needed for the current job. The reading logic is deliberately not applied from memory or from the router itself; fragments are always loaded from disk. This split keeps the static layer versioned and reviewable, keeps each invocation cheap by loading only the relevant fragment, and mirrors the sibling nature-writing and nature-polishing skills so shared content lives in a common _shared location.

The routing protocol has five steps performed every invocation. First, read manifest.yaml and every file listed under always_load, which hold the core principles, reading workflow, output contract, and the shared Terminology Ledger. Second, detect the source_format value (pdf-text as the default, plus scanned-pdf, html, doi-arxiv, and pasted-text) using the manifest's detect hint and state it in one line so the user can correct it cheaply; a source may map to more than one value, in which case the resolution fragment is loaded first. Third, load only the matching fragment(s) rather than every file. Fourth, build the reader by applying core principles, then the source-format fragment, then the six-step source-map-first reading workflow, then the output contract, building the Terminology Ledger as translation proceeds to populate the recurring-term table and source_map.json glossary. Fifth, open the on-demand references for figure/table cropping, output schema, or grounding rules only when needed. If constraints prevent full processing, it still creates a draft reader and labels missing pages, figures, or low-confidence crops in translation_notes.md rather than switching to summary mode.