write-paper-guide

A User’s Manual

A reading companion to one mathematical paper.

One paper, one reader, one guide.

Last revised: 2026-09-11

torsor lab

torsor.org

1 Preface: The Paper and You

Let’s be honest with each other. There is a paper you need to understand, and reading it again is not working.

Maybe it’s forty pages and the part you actually need is Section 6, which rests on Section 4, which assumes a construction the authors describe as standard. Maybe you’re refereeing it in three weeks. Maybe a student is presenting it in your seminar and you would rather not meet the hard parts at the same moment they do. Whatever brought you here, the paper is not the problem. The paper is fine. The problem is the distance between what it assumes and what you have.

That distance is specific to you. A colleague two doors down would need a different paragraph explained, and would skim the one you need most. This is why ``go read the survey first” so often fails — a survey is written for nobody in particular, and you are somebody in particular.

write-paper-guide produces a reading companion to one paper, calibrated to one reader. The output is a book in the same design as this one: PDF, HTML, EPUB, and Markdown, built from LaTeX source you can edit. It comes in two parts. Part I orients you — what the paper is about, why anyone wanted it, why it is hard, what is new in it. Part II walks the paper itself, following its own sections and its own numbering, saying what carries each argument and where the difficulty actually lives.

It writes about the paper in the third person, always. The authors prove; Section 3 establishes; Theorem 4.2 states. A guide is not a contribution and must never read like one. It explains a paper that already exists, and every sentence in it should be checkable against that paper.

Three chapters follow. Chapter 1 is the shape of the thing: two parts, one reader, and why the calibration step is the one that decides whether the guide is any good. Chapter 2 is how to run it — what it asks you, how to answer, and how to pre-answer everything when you would rather it not stop. Chapter 3 is what lands on disk, how to rebuild it, and what to do when the math does not survive the trip to HTML. The appendix collects the commands and conventions worth looking up rather than memorizing.

If there is a paper open on your desk right now, Chapter 2 is the one.

2 Two Parts, One Reader

A reading guide has two parts and one reader.

That’s the whole model. Everything else in this manual is detail.

2.1 The reader comes first

Before any outline exists, the skill asks who the guide is for. Field and subfield, and how close that is to the paper’s area. What they already know against what needs developing. Why they’re reading — refereeing, building on it, teaching from it, a seminar, curiosity. How much depth they want, and how much length they’ll tolerate.

Those answers are written to latex/reader-profile.md inside the guide directory, and they are the tie-breaker for every later decision about how much to explain. The file is not compiled into the book. It sits beside the source as the record of what the guide was calibrated to, which matters when you come back in six months and wonder why Chapter 1 spends four pages on a construction you find obvious.

The calibration is the step that decides whether the guide is worth anything. A guide written for a generic reader develops the prerequisites that reader happens not to need and skips the one that actually blocks them. Answering the interview carefully costs you five minutes and is repaid on the first page.

Note

The reader profile describes what someone is familiar with, never how good they are. ``Comfortable with derived categories, hasn’t had reason to use perverse sheaves” is a calibration. ``Expert” and ``beginner” are grades, and grades tell the guide nothing it can act on.

2.2 Part I — the overview

Part I answers six questions about the paper. The default is two chapters, but the grouping bends to fit the paper; what doesn’t bend is that all six get answered.

The failure mode of Part I is generic admiration, and it is worth naming because it writes itself. ``The paper makes a significant contribution to a central problem” answers none of the six questions. ``Previous results needed the base field to be algebraically closed, and the obstruction was the descent step in Section 4” answers two of them.

2.3 Part II — the walk-through

Part II follows the paper’s spine. A short roadmap chapter first: the paper’s structure at a glance, what depends on what, a reading order, and what to skim on a first pass. Then one chapter per major section or cluster of results, taking the paper in its own order.

Each of those chapters does four things. It says what that part of the paper accomplishes. It restates the results that matter, carrying the paper’s own numbering. It explains how the argument is built — which lemma is the engine and which are bookkeeping. And it says where the difficulty is, so you know what to read line by line and what to take on faith the first time through.

Restated results are set in theorem environments that print the paper’s own number:

\begin{paperthm}[Theorem 4.2, slightly informally]
  ...
\end{paperthm}

Carrying the number is not decoration. It is what lets you check the guide against the paper in ten seconds, which you should do the first time a restatement surprises you. A paraphrase is always marked as one.

2.4 The appendix

Last comes a notation and reference card: the paper’s notation collected in one place, and a table mapping the guide’s chapters to the paper’s sections. This is the part you search rather than read, and it is deliberately dense so the prose chapters don’t have to be.

2.5 What it is not

A guide is not a survey. Context appears in service of this paper, not as a tour of the field.

A guide is not original work. If a sentence reads as a new result, it is in the wrong document — and if the guide fills a gap the paper left, it says that plainly rather than quietly closing it.

A guide is not a summary either. A summary gets shorter; a guide gets longer, because the compressed passages are exactly the ones worth expanding.

3 Running It

Point the skill at a paper and answer a few questions. The rest is a conversation with checkpoints.

3.1 Starting

Invoke it with whatever identifies the paper — a path to a PDF, an arXiv identifier or URL, or enough of a citation to find it:

/write-paper-guide ~/papers/descent.pdf
/write-paper-guide arXiv:0000.00000
/write-paper-guide the paper on heights of
  special points that everyone cites

Given only a citation, it finds the paper and confirms with you that it has the right one before investing in a full read. Confirm carefully. A guide to the wrong paper is expensive in a way that is not obvious until page thirty.

Then it reads the paper — properly, not the abstract — and does not start writing until it can state in one paragraph what the paper proves and how. If that paragraph looks wrong to you when it appears, say so immediately rather than waiting to see whether the guide recovers. It won’t.

3.2 The reader interview

Next it asks about the reader, as a short batch of questions rather than one at a time. Answer them for whoever will actually read the guide. If that’s you, say so and answer from your own position.

You can skip the interview by pointing at a document instead: notes you already have, or a profile file for this reader if you keep them. It reads that, tells you how it read it, and proceeds.

Note

Two answers do more work than the rest. Why they’re reading sets what counts as the point — a guide for a referee and a guide for a seminar speaker diverge almost immediately. What they already know decides how much of Part I is setup. Spend your effort on those two.

3.3 Where it lands

Then it proposes a location and waits. A paper sitting in its own folder usually gets a guide/ subdirectory beside the PDF; a loose paper gets a new directory named for it, somewhere you choose.

If a guide directory is already there, it looks at what’s in it and asks whether to extend it or start fresh. It doesn’t overwrite anything without asking.

3.4 The outline

Next comes the proposed outline: the two parts, the chapters within them, and the appendix. This is the cheapest moment in the whole process to change your mind about scope, so read it properly. Merging two chapters here costs a sentence. Merging them after they’re written costs a rewrite.

The voice is settled at the same time. The default is 01-direct, which is the register this manual is written in and the one the family is tuned for. There is a more digressive 02-wandering if you want it; ask for it by name at this point.

3.5 Writing, with checkpoints

Part I is written first, in full, and shown to you before Part II begins. That order is deliberate: Part II inherits Part I’s framing and depth, so a correction made at the end of Part I is a correction to everything, and the same correction made later is not.

Part II then arrives a chapter at a time, each one shown to you before the next is started. The thing worth watching across those checkpoints is proof depth — how much of each argument gets reconstructed. It’s the dial most likely to be set wrong at first, and the one that’s cheapest to adjust early. Say ``more detail on the proofs” or ``less” and it carries forward.

The roadmap chapter is written early, since it frames the rest. The notation appendix is written last, once there’s something to collect.

3.6 Running it without checkpoints

Sometimes you don’t want a conversation. You want to come back to a finished guide. Pre-answer everything it would stop to ask, in one argument string:

/write-paper-guide The paper is at
~/papers/descent.pdf. Do not ask me anything --
take every default and proceed. The reader is an
active researcher in an adjacent field:
comfortable with the general area and its
standard machinery, familiar with the objects by
name, but not a specialist in this corner and
without the local folklore. They are reading in
order to referee it, so go to proof depth and
skip nothing -- where the paper compresses,
reconstruct. Length: exhaustive, no budget.
Location: ~/papers/descent/guide/.

That covers the paper, the reader, the purpose, the depth, the length, and the location, which is everything the skill would otherwise pause on. This is exactly how write-critical-guide drives it as a subroutine, and it is the pattern to copy when you want an unattended run.

Warning

An unattended run gives up the checkpoints, and the checkpoints are where the depth gets corrected. If the depth comes out wrong, the fix is another full run, not an edit. Pre-answer when you’re confident about the reader and the depth; keep the checkpoints when you’re not.

4 What Comes Back

A guide directory is a self-contained book. You can move it, hand it to someone, or rebuild it on a machine that has never had the plugin installed.

4.1 The directory

guide/
  Makefile
  check-build.py       verification, copied in
  tex2torsor/          converter, copied in
  latex/
    main.tex           preamble, title, inputs
    STYLE.md           the style guide in force
    reader-profile.md  the calibration
    chapters/
      00-preface.tex
      01-what-its-about.tex
      ...
      99-notation-and-reference.tex
  html/
  epub/
  markdown/            build output

The tools are copied in rather than linked, which is why the directory survives a plugin update or an uninstall. It also means each guide carries its own copy, so a fix to the converter reaches old guides only if you copy it over.

STYLE.md is assembled when the guide is scaffolded: the format mechanics for this genre, followed by the voice file, with a header recording which voice was used. It is the answer to ``why is it written like this” and the thing to read before editing prose by hand.

4.2 Building

Four formats, four targets:

make pdf    latex/main.pdf, via latexd
make html   html/manual.html, via tex2torsor
make epub   epub/manual.epub, via pandoc
make md     markdown/manual.md, GFM
make check  verify the build
make view   build html, open it in lab-view
make clean  remove the build output

The PDF is the format the design is tuned for and the one to trust. The others are conveniences: HTML to read on a screen or send a link to, EPUB for a tablet, Markdown for grep and for pasting into a message.

Warning

latexd exits 0 even when LaTeX has failed, so make pdf && echo ok can lie to you. make check is what catches it — it verifies the PDF exists, is newer than every source file, has a sane page count, and that the log carries no errors or undefined references. Run it. A one-page PDF where you expected forty is the usual shape of the failure.

4.3 Verification

Note

latexd compiles in a temporary directory and does not keep the LaTeX log, so after a latexd build make check has no log to read and fails on that alone. Build once with latexmk and the log lands in latex/, where the checker looks:

latexmk -pdf -cd latex/main.tex

Or point the checker at a log elsewhere with its --log option.

make check is the mechanical tier. It reports LaTeX errors, undefined references and citations, overfull boxes with their overrun in points, non-ASCII characters inside listings, and missing EPUB or Markdown output. Exit 0 with warnings is possible, so read the report rather than the exit code.

Above that sits the publication pass, which is the gate the whole family shares. It runs the mechanical checks, then inspects a targeted sample of pages by eye — title page, colophon, one page per chapter, every page a mechanical check flagged, and the display math — and returns an evidence report. Not ``everything looks good”: page counts, specific findings with page numbers, and an explicit list of what was accepted as an exception. The guide is not finished until that report is clean.

4.4 When the math doesn’t survive

The PDF renders everything. The HTML and EPUB paths are weaker, and they fail quietly, which is worse than failing loudly.

The converter cannot handle over-accents such as \ widetilde and \overline, \frac, extensible arrows, or array and aligned — which means commutative diagrams. What you get instead is raw TeX sitting in the page where an equation should be.

Three fixes, applied to the guide and not to the shared converter:

The other thing that needs telling: if the guide uses pitfallbox — the callout for the subtlety that actually trips people — the converter drops it in HTML unless you pass it a mappings file that says how to render it. The mapping is four lines of YAML and lives in the family lessons.

4.5 Editing it afterwards

It’s LaTeX. Edit the chapter files and rebuild. Two habits worth keeping: don’t touch the palette, fonts, or box definitions in the preamble, since those are what make the family look like a family; and re-run make check after editing, because the failure you just introduced is the quiet kind.

If you want more than an edit — a chapter added, the depth changed throughout — hand the guide back to the skill and say what should be different. It reads what’s there and works alongside it rather than starting over.

5 Quick Reference

Everything worth looking up rather than remembering.

5.1 Invocation

/write-paper-guide <pdf path>
/write-paper-guide arXiv:<id>
/write-paper-guide <citation or description>

Unattended template — pre-answers every question the skill would stop on:

The paper is at <path>. Do not ask me anything --
take every default and proceed. The reader is
<field, and how close to the paper's area>: <what
they know>, but <what they lack>. They are
reading in order to <purpose>, so <depth
instruction>. Length: <budget or "exhaustive">.
Location: <path>/guide/.

5.2 Make targets

Target What it does
pdf latex/main.pdf via latexd, falling back to latexmk
html html/manual.html via tex2torsor
epub epub/manual.epub via pandoc
md markdown/manual.md, GitHub-Flavored Markdown
check run check-build.py: log scan, freshness, format checks
view build HTML and open it in lab-view
clean remove html/, epub/, markdown/

5.3 Files in a guide directory

Path What it is
latex/main.tex preamble, title page, chapter inputs
latex/STYLE.md base mechanics + voice; records the voice
latex/reader-profile.md the calibration; not compiled
latex/chapters/ one .tex per chapter
check-build.py verification, copied in
tex2torsor/ HTML converter, copied in
html/, epub/ build output; gitignored
markdown/ build output; gitignored

5.4 Structure

Part Contents
Preface what the paper is, how to use the guide
Part I the six questions, usually in two chapters
Part II roadmap, then one chapter per major section of the paper
Appendix notation card, plus chapter-to-section map

The six questions of Part I: what it is about; why it is interesting; why it is plausible; why it is hard; why it is new; why the authors were able to pull it off.

5.5 LaTeX conventions

Macro or environment Use
\code{} inline command, file, field, or flag name
lstlisting multi-line code; ASCII only
notebox something a reader might genuinely miss
warnbox real harm: data loss, a build that lies
pitfallbox the subtlety that actually trips readers
paperthm restate a theorem, carrying the paper’s number
paperdefn likewise, a definition
paperlem likewise, a lemma
paperprop likewise, a proposition

Restatements always carry the paper’s own number in the optional argument:

\begin{paperthm}[Theorem 4.2, slightly informally]

5.6 Voices

Voice Register
01-direct the default and the proven one: direct, dry, leads with the point
02-wandering experimental; digressive, several lines of thought braided

Ask for a non-default voice when the outline is confirmed. The choice is recorded in reader-profile.md and in the STYLE.md header.

5.7 Words the house does not use

Utilize (use ``use”), leverage, seamless, robust, powerful, simple, easy, straightforward, clean, load-bearing. Also we prove and our result, which belong to the paper and not to a guide; elegant and beautiful as filler; and any throat-clearing that opens a section without saying anything.

Numbers: spell out one through nine, numerals for 10 and above, and always numerals for theorem, section, equation, page, and reference numbers.

5.8 When the math doesn’t render

Symptom Fix
EPUB shows raw TeX add --mathml to the epub pandoc call
HTML shows raw TeX add inject-mathjax.py as a post-step to html
Diagrams and over-accents lost write renderable notation; note the paper’s glyph in prose
pitfallbox gone in HTML pass a mappings YAML to the converter with -c
PDF is one page, build ``succeeded” latexd lied; read latex/main.log
make check finds no log latexd discards it; build once with latexmk

5.9 What has to be installed

Tool Needed for
pdflatex the PDF; with ebgaramond, cabin, microtype, mdframed, titlesec, fancyhdr, listings
latexmk driving the PDF build (latexd wraps it)
pandoc HTML, EPUB, and Markdown
python3 the converter and check-build.py
lab-view optional; only make view uses it