What is Spark-To-Paper-Skills/spark-to-paper-skills?

The project packages 13 Claude Code skills plus an orchestrator that plans experiments, writes LaTeX sections and redraws figures as editable vectors. It is a plugin, not a standalone app, and that shapes both what it can do and what it costs to run.

Can I use Spark-To-Paper-Skills/spark-to-paper-skills commercially?

Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is Spark-To-Paper-Skills/spark-to-paper-skills still maintained?

Yes. The repository last received commits 29 days ago.

What programming language is Spark-To-Paper-Skills/spark-to-paper-skills written in?

Mainly Python, according to GitHub's language statistics.

spark-to-paper-skills: what this Claude Code paper tool is

At a glance

What is it?: The project packages 13 Claude Code skills plus an orchestrator that plans experiments, writes LaTeX sections and redraws figures as editable vectors. It is a plugin, not a standalone app, and that shapes both what it can do and what it costs to run.
Who is it for?: Adopt it if you already work inside Claude Code and want a first draft with real BibTeX entries and vector figures you can edit, and if you accept roughly $10 in API spend per paper plus an environment that must supply LaTeX. Do not adopt it if you need a standalone web app, a hosted service, or a workflow that runs without an LLM session.
Can I use it commercially?: Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository last received commits 29 days ago.
What is it written in?: Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 18, 2026 · Spark-To-Paper-Skills/spark-to-paper-skills

The gap between a research idea and a submittable draft

Most of the work between "I have an idea" and "I have a PDF" is mechanical. You search for related work, you build a bibliography, you write experiment code, you produce tables, you draw figures, you format everything into a venue template. The intellectual part is a small fraction of the elapsed time, and the mechanical part is exactly what language models are now good at.

spark-to-paper-skills targets that mechanical layer. The README frames the input as a one-line idea, a proposal, or data, and the output as a compiled PDF with real references, editable vector figures and machine-checked integrity. The intended user is someone who already has a research direction and wants a draft to react to, not someone looking for the system to invent the direction. The repository describes the typical cost as about $10 in API calls per paper, which is the number to keep in mind when deciding whether this fits a workflow.

One orchestrator, 13 skills, and an artifact tree per run

There is no server and no separate application. The repository is a Claude Code plugin: the .claude-plugin/ directory holds the plugin manifest, and skills/ holds 13 composable skills. A single orchestrator inspects your input, picks a mode, and chains the skills. The README states that the orchestrator auto-routes the input and runs the full chain.

Each run leaves a concrete tree rather than a chat transcript. According to the README's output table, you get main.tex and main.pdf compiled in the selected venue template, one LaTeX file per section plus the abstract under sections/, a blueprint.json holding the structured title, keywords, contributions, notation and word targets, a refs.bib with BibTeX entries whose citation records are checked via WebSearch and Crossref when available, and figures/ with SVG, PDF and PPTX versions. Experiments live under experiments/, and logs/*.io.md records an INPUT / DECISIONS / OUTPUT trace for every stage. A run_gates.py script checks the deterministic gates: citations, draft, vectors, LaTeX.

The blueprint is the piece worth noticing. It is written before the prose, so the word targets and contribution list are fixed early and the section writers work against them. That is a different architecture from asking a model to write a paper in one pass, and it is why the output arrives as many small files instead of one long document.

Installing the plugin and running a first paper

The README gives a single install command. It clones the repository into the Claude Code skills directory, and the README states the plugin auto-loads on the next Claude Code session. There is no package manager step and no build.

bash

git clone https://github.com/Spark-To-Paper-Skills/spark-to-paper-skills.git ~/.claude/skills/spark-to-paper-skills

After that, you start a session and address the orchestrator with your idea. The README's example is a single line, and the orchestrator handles routing.

code

Run ts-paper on this proposal.

Configuration is a unified .env file. The repository ships .env.example, which says to copy it to ./.env; the file is gitignored and is auto-loaded by the skill scripts through _dotenv.py. An exported environment variable always overrides a value in the file. Several keys are optional and fall back to other sources, but the image-generation block is explicit about needing a model choice and a key.

bash

cp .env.example .env
# then edit .env: set TS_FIG_MODEL, TS_FIG_API_KEY, TS_FIG_BASE_URL

The .env.example lists TS_FIG_MODEL with a default of gpt-image-2 and alternatives including gpt-image-1, dall-e-3 and gemini-3.1-flash-image-preview, plus TS_FIG_API_STYLE to switch between the OpenAI /images/generations endpoint and /chat/completions. TS_FIG_SIZE defaults to 1536x1024 and TS_FIG_QUALITY to high. One key is one-time only: HF_TOKEN is described as needed solely when first provisioning the DrawAI runtime to download the gated SAM3 model plus PaddleOCR and RMBG, and not used at run time once models are deployed. The comment adds that you must accept the SAM3 model terms on its Hugging Face page.

What you should see after a successful run is the artifact tree described above. What the README does not describe is the LaTeX toolchain. Since the output includes main.pdf, a working TeX installation is implied, but the install section does not mention one, so treat that as something you verify on your own machine before blaming the pipeline.

The figure engine is where the design opinions live

Figures are the part of this project with the most specific point of view. The README describes a two-step process. The official PaperBanana renders candidate figures. Then a skill called ts-figure-svg learns the render's design language and redraws the figure natively from the paper's facts, iterating against a geometry audit, audit_svg.py, until it passes. The audit is described as stdlib-only, meaning it runs without extra dependencies.

The stated result is live text elements rather than a traced bitmap. That distinction matters if you plan to edit a figure later: a traced bitmap forces you to redraw from scratch, while an SVG with real text nodes lets you change a label. The README calls this a core project focus, and the v1.2 release note names it as the PaperBanana+ figure engine.

There is a second path for free-form schematics, which uses image generation models configured through TS_FIG_MODEL. The GPT vision and text-correction path in ts-figure-optimize is separate again, and its keys are optional because they fall back to ~/.codex/auth.json when unset. So the figure pipeline has at least three configurable surfaces: a vision model, an image-generation model, and a local audit script. That is more moving parts than most of the other stages, and it is where configuration mistakes will show up first.

What the project does not do for you

The README is candid that citation records are checked via WebSearch and Crossref when available. The qualifier does the work: when those sources are unavailable, the check is weaker, and a plausible-looking BibTeX entry is not the same as a verified one. Anyone planning to submit should still open the references.

The larger limitation is the dependency on Claude Code. This is a plugin, and the README says so plainly with the phrase no separate app or orchestration server. That is a feature if you already live in that environment. It is a disqualifier if you need a web interface, a batch job that runs without a session, or a CI pipeline that produces papers unattended. There is no documented headless mode, and the .env.example's Overleaf block is described as off by default via paper_config.yaml: require_overleaf_url=false and only relevant to Stage 8 ts-paper-experiment. The README does not document rollback for a partially completed run, so if a stage fails midway, how you resume is not specified.

Cost is the other boundary. The project's own figure is about $10 in API costs per paper, and that is on top of whatever Claude Code access costs you. Running many iterations to improve a draft multiplies it. For a one-off draft this is cheap; for a lab generating dozens of variants it is a budget line.

How it compares to a general writing assistant

The obvious alternative is using a general-purpose assistant and asking it to write the paper. The difference is structural rather than qualitative. A chat assistant produces prose in a conversation; there is no blueprint.json fixing the contributions and word targets before writing starts, no per-section LaTeX files, no refs.bib assembled from Crossref lookups, and no run_gates.py checking citations, draft, vectors and LaTeX as separate deterministic gates.

A second alternative is a LaTeX template plus manual work. That gives you full control and no API spend, and for a short paper it may be faster than configuring a plugin. What it does not give you is the experiment stage, which the README places at Stage 8 and describes as auto-run experiment code with filled result tables. Whether that stage is useful depends on your field: it works when experiments are code, and it is irrelevant when they are wet-lab work or human studies.

The honest comparison is this. If your bottleneck is formatting and bibliography assembly, a template plus a reference manager solves it with fewer dependencies. If your bottleneck is the whole chain from idea to a draft you can critique, the composable-skill approach is doing more work per invocation, and the artifact tree is the evidence.

Maintenance, licensing and what an upgrade costs you

The repository is not archived, and the last push was on 2026-08-22. Releases are frequent and small: v1.0.1 on 2026-06-26 added a soft update check, v1.1.0 the same day brought Claude Code plugin support with .claude-plugin/plugin.json, and v1.2 on 2026-08-07 added the PaperBanana+ native SVG figures. The version history suggests the project is still changing its shape rather than only fixing bugs, so a pinned clone is safer than an unpinned one if you need reproducible output.

The update mechanism is described as non-blocking. check_update.py queries the GitHub Releases API on each run with a 24-hour cache, stays silent when up to date, and the README says it never blocks. That is a low-cost upgrade path, but it also means a run can pick up new skill behaviour without you noticing, which is worth knowing if you are comparing drafts produced weeks apart.

Licensing is MIT, which is permissive and places few constraints on reuse or modification. The practical caveat is that the licence covers this repository, not the models it calls. Your API keys, the image-generation model you select, the gated SAM3 download, and any venue template you compile against each carry their own terms. That is a description of where the boundaries sit, not legal advice; check the terms of the services you configure.

Editorial conclusion

Adopt it if you already work inside Claude Code and want a first draft with real BibTeX entries and vector figures you can edit, and if you accept roughly $10 in API spend per paper plus an environment that must supply LaTeX. Do not adopt it if you need a standalone web app, a hosted service, or a workflow that runs without an LLM session. Before committing, verify three things: that your machine can compile LaTeX (the README's install line clones the plugin and says nothing about TeX), that every key in .env.example you actually need is filled in, and that the figures produced for your domain survive the geometry audit rather than looking like the traced bitmaps the project is designed to avoid.

Frequently asked questions

What is spark-to-paper-skills?

It is a Claude Code plugin made of one orchestrator and 13 composable skills that turns a one-line idea, proposal or dataset into a compiled paper draft. The output includes LaTeX sources, a refs.bib with checked citation records, editable vector figures and a compiled PDF.

How do I install spark-to-paper-skills?

The README gives one command: clone the repository into ~/.claude/skills/spark-to-paper-skills, and the plugin auto-loads on the next Claude Code session. You then copy .env.example to .env and fill in the keys you need, such as TS_FIG_MODEL and TS_FIG_API_KEY.

How much does spark-to-paper-skills cost to run?

The project describes the typical cost as about $10 in API calls per paper. That figure sits on top of your Claude Code access and any image-generation model you configure through TS_FIG_MODEL.

Official sources

Community notes