figures4papers: Chen Liu's Python Figure Scripts and the scientific-figure-making Skill

What figures4papers actually is, and who it is for

This is not a library you import. It is a personal collection: Chen Liu, a Computer Science PhD candidate at Yale University, keeps the Python scripts used to produce figures for his own papers in one repository. The README names Nature Machine Intelligence, ICML, NeurIPS and ECCV as venues where these figures appeared. The top level of the repository is a set of per-paper folders (figure_Brainteaser, figure_CellSpliceNet, figure_Cflows, figure_Dispersion, figure_ImmunoStruct, figure_RNAGenScape, figure_VIGIL, figure_ophthal_review) alongside an assets folder and a scientific-figure-making folder.

The intended reader is someone writing a paper who needs a bar plot, a radar plot, a line plot, a concept diagram or a trend plot that survives a reviewer's eye, and who would rather start from a script that already shipped than from matplotlib defaults. The second intended reader appeared later: someone using an AI coding agent who wants the agent to follow a written convention instead of guessing. The README credits Shan Chen for suggesting the skill integration, which is why the repository now contains both scripts and a skill definition.

The figure_* folders: what each one demonstrates

The README groups the output by figure type rather than by paper, and the folders map onto those types. figure_ImmunoStruct holds bar plots for quantitative comparison (the README points at figure_ImmunoStruct/figures/bars_comparison_IEDB.png). figure_Brainteaser holds bar plots for composition breakdown (brute_force.png). figure_Dispersion holds 3D spheres (illustration.png). figure_VIGIL holds radar plots and line plots (comparison_radar.png, comparison_posttraining.png) and a concept plot (concept.png). figure_ophthal_review holds a trend plot by month (trend_by_month.png).

That structure is the honest part of the project. Each folder is a worked example of one visual idiom, with the data and the export code that produced it. If you need a radar plot for a benchmark comparison, figure_VIGIL is the closest thing to a template. If you need a trend over months, figure_ophthal_review is. The repository does not claim these are general-purpose; the README describes them as my Python scripts, and the folder naming keeps that scope visible.

The scientific-figure-making skill and how an agent reads it

The skill lives in scientific-figure-making/ and is a documentation tree, not code. SKILL.md is described in the README as a quick reference covering metadata, when to use the skill, patterns and links. Under references/ sit api.md (API and conventions to implement: palette, helpers, export), common-patterns.md (reusable figure patterns), demos.md (real-world figure_* projects with URLs), design-theory.md (style rationale and design principles) and tutorials.md (step-by-step guides).

The mechanism is deliberately plain. An AI coding agent that has the repository open can be told to read those files before writing a plotting script, so the generated code follows the same palette, helper names and export path as the existing figure_* folders. The README gives a prompt template that names SKILL.md, design-theory.md and api.md explicitly and asks for both a PNG and a PDF output. There is no server, no plugin and no runtime component; the skill is text that the agent reads. That is also its main weakness, since nothing enforces that the agent follows it.

Installing the skill: path-based use or a symlink

There are two documented routes. The first requires no installation at all. Open the repository in your AI coding agent (the README names Cursor and Claude Code as examples), ask for a plotting script in a target folder, and tell the agent to follow the skill files by path. The README's template asks for a script at a target path, references the three skill files, mentions apply_publication_style, make_* helpers and finalize_figure, and specifies PNG and PDF output.

Create a publication-quality figure script at <target_path>.
Use the Scientific Figure Making skill conventions from:
- scientific-figure-making/SKILL.md
- scientific-figure-making/references/design-theory.md
- scientific-figure-making/references/api.md (palette, helpers, export)

Implement or adapt the patterns (apply_publication_style, make_* helpers, finalize_figure). See figure_* folders for reference scripts.
Input data: <describe your data or paste arrays>.
Output files: <name>.png and <name>.pdf.

The second route installs the skill so the agent can invoke it by name. From the repository root, create the agent's skills directory and symlink the skill folder into it. The README gives the commands per agent; for Cursor the pair is:

mkdir -p ~/.cursor/skills
ln -s "$(pwd)/scientific-figure-making" ~/.cursor/skills/scientific-figure-making

For Claude Code the directory is ~/.claude/skills and for Codex it is ~/.codex/skills, with the same symlink target name. The README states that you should restart the agent, or refresh its skill list, after linking. After that, the skill can be cited by name as well as by path. Note what is missing: no requirements file, no pinned matplotlib version and no environment setup appear in the README, so the Python dependencies are whatever the individual figure_* scripts import.

Where the skill approach breaks down

The skill is instructions, and instructions are advisory. An agent that reads design-theory.md can still emit a figure with the wrong palette or a font size that does not match the rest of your paper, and the repository has no test that would catch it. You have to look at the exported PNG or PDF, which the README's workflow does ask you to do.

The second limitation is scope. The README has a section titled Miscellaneous: figures not made end-to-end in Python, and it says those figures were made partially in Python and are included to acknowledge the time and effort spent on them. The assets listed there (ImmunoStruct_schematic.png, VIGIL_teaser.png, RNAGenScape_schematic.png, Dispersion_motivation.png and others) are not reproducible from the scripts in the same way the figure_* outputs are. If your figure is a schematic assembled in a vector editor, this repository gives you the exported result and not the pipeline.

Third, the per-paper folders are tied to their papers' data. Nothing in the README describes a shared data format, so adapting a script means replacing its input handling as well as its styling.

How this differs from a plotting library or a style sheet

A plotting library such as matplotlib gives you primitives and a default style; a style sheet or a theme package gives you a reusable set of rcParams. figures4papers gives you neither as a package. It gives you finished scripts plus a written convention, which is a different trade. You get to see how a specific radar plot or composition bar plot was assembled, including the parts that are awkward in a library, but you get no versioning, no changelog and no release to pin. The repository's recent releases list is empty, so there is nothing to track beyond the main branch.

Compared with copying rcParams from a style sheet, the skill route adds an agent-readable rationale: design-theory.md explains why the choices are what they are, and api.md names the helpers to implement. That is more useful for a first draft and less useful for a team that needs identical output across many machines, because a style sheet is a file you can vendor and a skill is a document an agent interprets.

Maintenance, licensing and what to check before copying

The repository is not archived, and its last push was on 2026-09-06, which is recent. There is no release history to speak of, so upgrades mean pulling the main branch and re-reading the skill files if they changed. The cost of adopting the scripts is low because they are scripts; the cost of adopting the skill is the cost of reviewing whatever your agent generates against the existing figure_* outputs.

On licensing, GitHub reports the license as NOASSERTION, meaning it could not match the LICENSE file at the repository root to a recognised identifier. The README asks readers to cite the related papers where relevant and, in Chinese, to cite them within the bounds of academic norms. That is a request about citation, not a statement of reuse terms. If you plan to copy code into a paper's artifact or a product, read the LICENSE file itself rather than relying on the GitHub label, and treat the citation request as separate from the license.

Editorial conclusion

Adopt figures4papers if you are preparing a paper figure and want a working reference for style conventions and export, or if you use an AI coding agent and want it to follow a named skill instead of improvising matplotlib defaults. Do not adopt it expecting an installable plotting library, a stable API, or support for figures that were not made end-to-end in Python; the README itself lists several assets that were only partly made in Python. Before copying anything, open scientific-figure-making/references/api.md and confirm the helper names (apply_publication_style, make_* helpers, finalize_figure) match the script you intend to adapt, and check the LICENSE file at the repository root, since GitHub reports the license as NOASSERTION rather than a recognised identifier.

Frequently asked questions

Official sources

1. ChenLiu-1996/figures4papers on GitHub
2. Issues
3. Project website
4. README