build-research-paper

build-research-paper — Research Paper Builder Skill

Turn a project's results + figures + notes into a publication-quality, arxiv-ready PDF. This skill captures a pattern re-discovered across many research projects, distilled into two build paths: a LaTeX-first path (tectonic, the default) and a Markdown-first path (pandoc, the escape hatch).

First: a paper is a paper

Read this before touching main.tex, and re-read it before declaring done. Everything below is tooling. This is the point.

A paper is a document a human being reads, front to back, to learn something they did not know. That is the whole definition. Not a compliance artifact. Not a results dump. Not a receipt proving work occurred. Not a serialization of a task tree.

It follows that:

• The paper has a thesis — a story the data is telling. If you cannot say in one sentence what this paper found, it is not ready, regardless of how many sections exist. Write that sentence down before you write anything else.
• The reader is a domain expert, not a validator. They came for the finding. They will grant that you did the work carefully if you show them it holds; they will not read twenty pages of proof that it does before being told what "it" is.
• Figures carry the argument. A picture shows shape; a table files values. A data-analysis paper with no charts has not been written, only assembled.
• Rigor is the warrant, not the subject. Provenance, validation, failure logs and reproduction tests make the story trustable. They are not the story. When they migrate to the front, the paper has inverted itself.
• Nothing in the body may be unresolvable to an outsider. Internal task IDs, ticket numbers, commit SHAs and pipeline filenames mean nothing to a reader. If a sentence only parses inside your workspace, it is not prose.
• A paper is finished when someone has read it, not when the checks pass. Build the PDF, open it, and read it like a stranger would.