paper2code: an agent skill that turns arXiv URLs into citation-anchored code
Agent skill to turn any arxiv paper into a working implementation
At a glance
- What is it?
- paper2code is a Claude Code style agent skill that reads an arXiv paper and emits a Python project where each line of code cites the paper section or equation it implements. The useful part is the ambiguity audit, not the code generation.
- Who is it for?
- Adopt paper2code if you are reimplementing a paper whose details are scattered across appendices and you need to see, per line, whether the paper said it or the model guessed. Skip it if you want a training-ready repository: data download, distributed training, baselines and checkpointing are explicitly out of scope, and data.py is a skeleton with TODOs.
- 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 165 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 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap paper2code is aimed at: papers that omit their own implementation details
The README states the problem plainly: critical hyperparameters are buried in appendices or omitted, prose contradicts equations, and phrases like "standard settings" point at nothing. A team implementing such a paper spends its time doing detective work rather than writing model code. That is a real cost, but the sharper complaint in the README is about what happens when an LLM is pointed at the PDF instead. Naive generation fills every gap silently and confidently. The output runs, and nothing in it tells you which decisions came from the paper and which came from the model's priors. paper2code's answer is to make that boundary visible rather than to make generation smarter. The target user is an engineer who has to defend an implementation to a reviewer, a co-author or a colleague: someone who needs to know that layer norm epsilon was a default, not a finding. It is not aimed at someone who just wants a working baseline by Friday.
Citation anchoring: section and equation references attached to code lines
The mechanism is a comment convention. Every non-trivial decision in the generated source carries a reference to the paper location it implements, written as a section symbol plus a number, and an equation number where one exists. The README's example shows a TransformerBlock whose attention call is annotated with a section and an equation, and whose residual add is annotated with a section alone. The generated repository mirrors this at file level: the directory tree in the README labels model.py as citing section 3.2, loss.py as citing section 3.4, and train.py as citing section 4.1, with configs/base.yaml described as holding every parameter, each one either cited or flagged. This is the part that makes the output reviewable. You can open model.py, read the citations, and check each one against the PDF in a few minutes. The cost is verbosity: the code carries a parallel layer of provenance comments that will look noisy to anyone who treats the file as production source rather than as a reproduction artifact.
The ambiguity audit and the UNSPECIFIED flag system
Before any code is written, the skill classifies each implementation choice as SPECIFIED, PARTIALLY_SPECIFIED or UNSPECIFIED, according to the README. That classification lands in REPRODUCTION_NOTES.md, described as the ambiguity audit listing every choice, whether the paper specified it, and what alternatives exist. Inline, the same information appears as flags. The README gives two forms: an UNSPECIFIED comment that names the missing value, states the default chosen, and lists common alternatives (it uses LayerNorm epsilon as the example, showing 1e-6 chosen against 1e-5 and 1e-8), and an ASSUMPTION comment for cases where the paper's wording points somewhere without saying so directly. The README's own text for the second example is truncated mid-sentence, so the exact rule that separates an UNSPECIFIED flag from an ASSUMPTION flag cannot be confirmed from the material. Treat that distinction as the first thing to check in a real run. The design intent is clear enough: the flags are placed at the line where the choice is made, so the reader does not have to cross-reference a separate document to find out what was invented.
Installation and the invocation flags you actually pass
Installation goes through the skills CLI rather than pip. The README gives one command: npx skills add PrathamLearnsToCode/paper2code/skills/paper2code. The installer then prompts for three things: which coding agents to register the skill with (Claude Code is the example given), whether to install globally or at project level (global is marked recommended), and whether to symlink or copy the files (symlink is marked recommended). After that you start your agent normally and invoke the skill as a slash command. The README shows four forms. A full URL with no options produces a minimal implementation. A URL plus --framework jax switches the target framework. A bare arXiv ID such as 2106.09685 works without the URL prefix, and --mode full adds a training loop and data pipeline. A third mode, --mode educational, adds extra comments and a pedagogical notebook. Output lands in a directory named after the paper slug, containing README.md, REPRODUCTION_NOTES.md, requirements.txt, a src/ tree, configs/base.yaml and notebooks/walkthrough.ipynb. Requirements are pinned. The walkthrough notebook is described as runnable on CPU with toy dimensions and as performing shape checks, which is the cheapest way to confirm the generated code is internally consistent before you spend GPU time.
What the skill refuses to do, and why that is the honest part
The README lists six exclusions, and they define the tool's boundary more sharply than any feature list. It will not guarantee correctness: the README's position is that the implementation matches what the paper describes, so if the paper is wrong the code is wrong. It will not download datasets; data.py is a Dataset class skeleton with instructions on where to get data and how to preprocess it. It will not set up training infrastructure, meaning no distributed training, no experiment tracking, and no checkpointing beyond what the paper's contribution requires. It will not implement baselines, only the core contribution. It will not reimplement standard components: if the paper says "standard transformer encoder," the code imports it or notes the dependency instead of writing attention from scratch. And it will not invent details; missing hyperparameters get a common default plus a flag. The practical consequence is that the output is a reproduction scaffold, not a runnable experiment. You supply the data pipeline, the hardware plan and the baseline numbers. An engineer expecting a repository that trains after one command will be disappointed, and the README is upfront about that rather than burying it.
Where paper2code is the wrong tool
The failure mode follows directly from the citation convention. A paper that is well specified produces code with few flags and a short audit, which is exactly the case where a careful engineer reading the PDF would have done fine without the skill. A paper that is badly specified produces a long audit and a large number of flagged defaults, and the flags do not tell you which default is right for your setting. The tool surfaces the uncertainty; resolving it is still your job. There is a second limit around scope. Because baselines and infrastructure are excluded, paper2code suits a paper whose contribution is a self-contained architecture or loss, and fits badly a paper whose contribution is an empirical result that only means something inside a full training pipeline. The README also notes that the implementation follows the paper, so reproducing a paper with a known error in it will reproduce the error, with a citation attached. Finally, the skill is delivered as an agent skill rather than a library, so its behaviour depends on the host agent's model and context handling; the repository material does not document which agents or model versions were validated, and no releases are listed, so there is no versioned artifact to pin against.
The alternative: a direct prompt to a coding agent
The obvious comparison is pasting the paper into Claude Code or a similar agent and asking for an implementation. The difference is not code quality; it is where the uncertainty goes. A direct prompt produces code with no provenance layer, and any gap the paper left is closed silently, as the README itself argues. To get comparable information you would have to ask the agent to enumerate its assumptions as a separate step and then keep that list in sync with the code by hand. paper2code's contribution is doing that enumeration first, as a gate before generation, and then writing the result into the same files as the code, so the flag and the line it affects cannot drift apart. The trade-off is rigidity: you get the citation convention, the file layout and the three modes the skill defines, and nothing else. If your team already has a house style for reproduction repositories, the generated structure will conflict with it. A second alternative for narrow cases is finding an existing reference implementation and reading it, which sidesteps generation entirely; paper2code is for papers that have no usable public implementation, which is the situation the README describes.
Maintenance cost and licence
The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice; check the LICENSE file in the repository before redistributing, and note that the licence covers paper2code itself, not the papers you point it at or the code it generates from them. On maintenance: no releases are listed in the material, so there is no tagged version to pin, and installation is a live pull from the default branch through the skills CLI. That means an update to the skill can change the generated layout or the flag conventions between runs. For a one-off reproduction this does not matter. For a team that wants reproducible generated output across several papers, record which commit of the skill produced each directory, since the generated REPRODUCTION_NOTES.md captures the paper's ambiguities but nothing in the described layout records the tool version that wrote it. The last push recorded for the repository is 2026-04-03, so the project is active as of that date, but activity is not the same as a stable interface.
Editorial conclusion
Adopt paper2code if you are reimplementing a paper whose details are scattered across appendices and you need to see, per line, whether the paper said it or the model guessed. Skip it if you want a training-ready repository: data download, distributed training, baselines and checkpointing are explicitly out of scope, and data.py is a skeleton with TODOs. Before relying on it, open REPRODUCTION_NOTES.md for the paper you care about and count how many entries are marked [UNSPECIFIED]; that ratio tells you how much of the output is the paper and how much is a common default.
Community notes