ape-write-paper

Write Paper Skill

Turns a pile of source material (repo, docs, experiment logs, result JSONs, notes) into a conference-style paper and a compiled PDF. The goal is a paper a skeptical reviewer can follow in one pass and check number by number.

Priorities, in order: correct, then clear, then polished. A beautiful paper with one invented number is worse than a plain one with none.

Workflow

Run these phases in order. Do not start writing prose before phase 2 is done.

1. Gather and obey constraints

• Read every project instruction file first (AGENTS.md, CLAUDE.md, venue notes). Typical rules: target conference, approved title, author identity, layout, forbidden claims, which results may appear. They override this skill.
• Venue template check: If a specific conference or journal is targeted (e.g., ACM SIGMOD/VLDB requires acmart; IEEE requires IEEEtran; NeurIPS/ICML/ACL require their .sty packages), use the official conference documentclass and native metadata commands (\begin{CCSXML}, \keywords, \author{...}\affiliation{...}) rather than the standalone title block from reference/preamble.tex. See reference/snippets.md for the ACM acmart skeleton.
• Read the existing draft if there is one. Treat its numbers as unverified until traced.
• Read all of: design docs, evaluation files, result JSONs, benchmark scripts, training logs, tests. Read the scripts too, to learn the real protocol (prompts, normalisation, hardware pinning, warmups, metric definitions).
• Find the tooling: which pdflatex xelatex tectonic typst. Prefer what is installed. See reference/preamble.tex for engine-specific notes.

2. Build a claim ledger (before writing)

Make a table in your scratch space: claim | value | source file | verified?. Every number, speedup, count, percentage, throughput, latency percentile, and comparison that will appear in the paper gets a row.

Rules:

• A number enters the paper only if it traces to a file you opened, or to a computation you ran from such a file. Recompute derived numbers (speedups, gaps, intervals) yourself.
• Check counts against raw data, not against prose. Draft tables often carry wrong N per category; count the items.
• If a number appears only in a doc and not in a reproducible result file, either use it with its provenance stated ("measured separately") or flag it to the user as unreproducible.
• Delete what has no source: invented curves, estimated costs, baselines never run, market claims ("30-40% of fields..."), competitor tables from memory, hardware names you cannot confirm. Do not soften them, remove them.
• Never add results for systems that were not actually run. A baseline that cannot be run is described qualitatively, or by construction, not with a number.
• Discrete uncertainty: Compute Wilson 95% interval for proportions on small samples. State N next to every percentage that matters.
• Continuous variance: For continuous measurements (latency, throughput, runtime, loss), report mean $\pm$ standard deviation, confidence intervals, or median with tail percentiles (p95, p99, p99.9) across seeds or repeated runs. Never quote a single cherry-picked run as a general fact without explicitly stating it was an unrepeated single run.
• Systems & Database metrics: For systems/DB workloads, track throughput (QPS, ops/sec), tail latency (p99, p99.9), multi-core scalability ($1 \to N$ threads), memory footprint (peak RSS, bytes per record), and write/read amplification.