Spark-to-Paper: End-to-End Research Paper Generation as a Composable Skill
Zhuoyang Qian, Biao Wu, Yiran Wang, Chris D Yan, Desan Dai, Liangwei Zheng, Jin Jiang, Junsheng Zhang, Wenhao Wang
cs.CL
2026-08-12
Spark-to-Paper runs 13 skills inside a coding assistant to draft full papers, reaching 99.5% citation validity and raising fabrication detection from 14% to 92%.
Turning a research idea into a full paper is not just about generating text: you have to find the literature, design and run experiments, decide whether the evidence actually supports the claim, produce publication-ready figures, and keep dozens of pages consistent as the manuscript evolves. Existing autonomous research systems (AI Scientist, Agent Laboratory, and others) automate this whole loop, but they ship as standalone applications with their own orchestration layer, sometimes even a dedicated database, separate from the coding environment researchers actually work in day to day. The question this paper asks is direct: can the whole idea-to-paper pipeline be built as reusable skills that drop into an existing coding assistant, like Claude Code, instead of standing up a new agent platform?
Spark-to-Paper is thirteen skills, each handling one research task (planning, literature retrieval, writing, review, figure generation, running experiments), communicating through a shared project directory: one skill writes its output as files, the next skill reads them and continues. Two divisions of labor run through the whole design:
To address a failure mode common in long research trajectories, the paper names the Self-Refutation Loop: the system keeps concluding its own experiments don't support the original research objective, yet keeps revising the same direction rather than accepting the idea might just not work. Spark-to-Paper caps these experiment-critique-revision cycles at seven; past that, the attempt becomes a failure report and the system starts a fresh idea instead of dressing up a null result as success. Figures get a similar role split: plots reporting measured results come straight from plotting code run on the actual data, while explanatory figures like method diagrams start as a visual draft from an image-generation model, get reconstructed into editable HTML by the coding assistant, are rendered and compared against the draft, refined iteratively, and exported as vector PDF.
Across eight controlled research topics, Spark-to-Paper hits 99.5% citation validity and 96.4% figure-element editability, both ahead of previously released AI Scientist (93% citation validity, 0% figure editability), AI Scientist-v2 (91%, 3%), and Agent Laboratory (96%, 0%), none of which produce editable vector figures at all. A dedicated ablation injects 36 fabricated claims spanning ten failure families into the source material to test whether the system catches them: a single-pass draft catches 14%, adding deterministic gates raises that to 69%, adding self-review to 81%, and the full stack (gates plus self-review plus adversarial review) to 92%, with 74% of the issues the adversarial reviewer raises confirmed as real by blinded independent raters. The full system averages 11.9M tokens, $8.1, and 3.2 hours per manuscript, considerably more than a single-pass draft's 0.11M tokens, $0.66, and 16 minutes, but that single-pass draft's citation validity is only 81%. In a case study, researchers deliberately injected two wrong expectations into the proposal, that Accuracy should be the primary metric for imbalanced clinical data, and that causal decomposition models should match plain recurrent networks once data leakage is removed for electricity forecasting; after running its experiments, the system reached conclusions contradicting both and revised the manuscript's claims accordingly.
Rather than building yet another standalone agent platform for the whole research process, Spark-to-Paper shows this capability can live directly inside an existing coding assistant, no separate orchestration service, database, or scheduler to maintain, which lowers the adoption cost for teams already doing research inside tools like Claude Code. Its evidence discipline matters just as much: experiment design is locked before results are seen, numeric cells stay blank until something is actually measured, and claims get weakened, removed, or moved to limitations when new evidence contradicts them rather than being smoothed over by the writing model. Letting evidence drive what the manuscript says, instead of letting the manuscript decide how to spin the evidence, is what separates this from systems optimized purely for producing fluent-looking papers.
The paper doesn't have a dedicated limitations section, but the evaluation design hints at the boundaries: the eight controlled topics are a small set, and both case-study domains (clinical screening, electricity-load forecasting) have clear, checkable evaluation criteria, so it's untested on open-ended research questions without an obvious right answer. The fabrication-detection ablation uses 36 artificially injected probes, which may not match the distribution of errors that occur naturally in real research. Comparisons against AI Scientist and similar systems rely on post-hoc audits of those systems' publicly released papers rather than rerunning them on the same topics and model backbone, so cost and quality numbers aren't strictly apples-to-apples.