/write-paper

name: write-paper
description: Turn a project's verified fact graph into a publishable LaTeX paper in a configurable house style — a standalone amsart .tex with a real bibliography, compiled to PDF. Use when a project's target theorem is established and the operator wants the paper, or asks to write/revise/audit references for the paper for a project. NOT human-summary (a reader-facing progress report with no bibliography); this is the publication artifact, with verified citations, headed for arXiv / a LaTeX git repo.

write-paper — fact graph → publishable paper

You are the main agent. This skill turns a project's **verified fact graph** into a **publishable** LaTeX paper in a configurable house style: a standalone `\documentclass{amsart}` `.tex` with a real manual bibliography, compiled to a clean PDF, ready for arXiv / an Overleaf (or other) LaTeX git repo. It is the publication sibling of `human-summary` (a reader-facing progress report with no bibliography).

The heavy LaTeX work is delegated to a **local codex at extra-high (`xhigh`) reasoning** — the same codex machinery the workers and the verify service already use. The writer, auditor, verifier, and reviser roles are wrapped behind the `write-paper` MCP service (tools `paper_write` / `reference_audit` / `reference_verify` / `paper_revise`): you call them with structured args, the tool assembles each role's prompt internally (so the style guide and fact-graph bytes never enter your context) and drives the codex with each role isolated by construction. The reference chain is `auditor (offline, flags) → verifier (online, checks) → reviser (edits)`. You orchestrate the stages, call these tools, gate on compilation, and surface the one or two real decisions to the operator.

When to use

• A project's target theorem is established in the fact graph and the operator

wants the paper.

• The operator asks to **write**, **revise**, **audit references for**, or

**push** the paper for a project.

Do not use it for the progress report (`human-summary`) or for the dense pro consult input (`elaboration`).

Source of content: the fact graph (never your memory)

Build the mathematics from the project's **verified facts** (`<project>/fact_graph/facts/*.md`) and the verbatim goal in `<project>/PROBLEM.md` — exactly as `human-summary` does, but for publication:

• Each fact's `## statement` is fully-quantified and self-contained → render into

the paper's theorems/propositions (clean LaTeX, do not paraphrase loosely). Its `## proof` is the argument; `## intuition` feeds a proof sketch where useful.

• Load-bearing facts first: high dependency depth (headline results) and high

in-degree (key lemmas). `predecessors` give you the internal `Theorem~\ref{}` cross-reference structure **with zero invention**.

• **Citations come structured, from the source.** Each fact's `external_refs`

(key / authors / title / arxiv / year / cited_for) records the published results its proof cited. `driver/seed_ledger.py` aggregates them across the project into the starting `REFERENCE_LEDGER.md`. Do not re-mine citations from prose — that is the #1 failure mode (hallucinated references).

• **Preserve all mathematics. Invent nothing** — no assumptions, lemmas,

citations, theorem labels, or definitions that are not in the fact graph. If a step is unclear, flag `[GAP: ...]`, do not smooth it over.

Paper workspace: `<project>/paper/` (default) — and MULTIPLE papers per project

Per-project, alongside `fact_graph/` and `global_memory/`:

<project>/paper/                 # the DEFAULT paper (legacy paths — unchanged)
  PROJECT_BRIEF.md      # per-paper framing (interview the operator — see below)
  REFERENCE_LEDGER.md   # seeded from external_refs, verified by the auditor
  REVISION_LOG.md       # append-only round history
  main.tex / main.pdf   # the paper
<project>/TARGET.md              # the DEFAULT paper's finalized target (danus finalize)

Seed the workspace from `templates/` (copy `*.template` → the real names) if it does not exist yet.

**One project can hold MULTIPLE papers** (e.g. a main theorem paper + a companion, or several theorems each written up separately). Every `paper_*` tool and `danus finalize` takes an optional **`paper_id`**:

• `paper_id` **omitted / `"main"`** → the **DEFAULT** paper on the **legacy** paths

above (`<project>/paper/` + `<project>/TARGET.md`). Existing single-paper projects are byte-for-byte unchanged.

• any other `paper_id` (e.g. `thmB`) → an **isolated** workspace

`<project>/papers/<paper_id>/` with its own `PROJECT_BRIEF.md` / `REFERENCE_LEDGER.md` / `REVISION_LOG.md` / `main.tex` / `TARGET.md`. So N papers never collide — each has its own files.

There is **one fact graph per project** (`<project>/fact_graph/`); papers never fork or re-filter it. A paper's facts are simply the transitive-predecessor **closure of its own headline set** — the SAME closure primitive the single-paper pipeline already uses, merely rooted at that paper's recorded target. The three shapes are one model — **a list of `{paper_id, headline_fact_ids}`**:

• **1 paper / 1 theorem** — the default: one entry, `paper_id="main"`.
• **N papers / 1 theorem each** — N entries, each a distinct `paper_id` and a

single-fact headline; written in **separate workspaces** (no overwrite).

• **N papers / one multi-theorem paper** — an entry whose `headline_fact_ids` is a

LIST of several targets; its fact set is the **union closure** of that list.

`paper_id` must be a single safe path segment (same validation as a project name); it cannot escape the project dir.

Style source

Two generic, self-contained layers under `style/`, neither naming an author or a field:

• `style/STYLE_GUIDE.md` — the compact baseline house style (binding for *voice*:

macros, theorem/proof shape, citations, cross-references, sentence-level rules).

• `style/PAPER_STRUCTURE.md` — the per-section content plan (binding for

*structure