figures4papers: ein Skript-Archiv für Publikationsgrafiken, kein Plot-Framework

Ein Archiv eigener Skripte, kein Paket für Dritte

Der Autor beschreibt das Repository als zentralisierte Sammlung seiner eigenen Python-Skripte für hochwertige Abbildungen. Chen Liu ist Doktorand an der Yale University, und die Grafiken sind laut README in Nature Machine Intelligence, ICML, NeurIPS und ECCV erschienen. Genau darin liegt der Wert und zugleich die Grenze: Es handelt sich nicht um eine Bibliothek mit Versionierung, Changelog und Issue-Tracking für Anwender, sondern um den Ablageort eines Einzelnen. Es gibt keine abgerufenen Releases, der letzte Push stammt vom 6. September 2026. Wer das Repository klont, bekommt den jeweils aktuellen Stand der main-Branch, ohne Stabilitätszusage.

Die Zielgruppe ist entsprechend eng: Forschende, die ihre eigenen Diagramme in Matplotlib nachbauen wollen und dafür ein funktionierendes Beispiel bevorzugen. Für sie ist die Struktur hilfreich, weil jeder Ordner einem Paper zugeordnet ist. Wer dagegen eine API sucht, die über Jahre hinweg gleich bleibt, ist hier falsch. Die Skripte sind an die Daten und die Argumentation des jeweiligen Papers gebunden. Das README benennt das offen: Die Ordner figure_* enthalten projektspezifische Skripte und Ausgaben.

Ordnerlogik: ein Paper, ein figure_*-Verzeichnis

Die Aufteilung folgt den Papern, nicht den Diagrammtypen. Im README stehen Balkendiagramme für quantitative Vergleiche aus figure_ImmunoStruct, Balken für Zusammensetzungen aus figure_Brainteaser, 3D-Kugeln aus figure_Dispersion, Radar- und Liniendiagramme sowie Konzeptgrafiken aus figure_VIGIL und Trendverläufe aus figure_ophthal_review. Wer eine bestimmte Darstellungsform sucht, muss also über den Papernamen gehen und nicht über eine Funktionsreferenz.

Ein zweiter Bereich heißt Miscellaneous und versammelt Abbildungen, die nicht vollständig in Python entstanden sind. Das README begründet die Aufnahme damit, den Zeitaufwand für diese Grafiken anzuerkennen. Für die Praxis ist das relevant: Diese Bilder liegen als PNG unter assets/ und sind keine ausführbaren Beispiele. Wer den Code sucht, muss auf die figure_*-Ordner schauen. Umgekehrt gilt: Nicht jede im README gezeigte Abbildung ist reproduzierbar, und das behauptet das Repository auch nicht.

Der Skill-Ordner als Schnittstelle zu Coding-Agenten

Der jüngere Teil des Repositories ist scientific-figure-making/. Das README nennt als Anlass den Hinweis eines Freundes und beschreibt die Hierarchie: SKILL.md als Kurzreferenz mit Metadaten, Anwendungsfällen, Mustern und Links, darunter references/ mit api.md, common-patterns.md, demos.md, design-theory.md und tutorials.md. Die Aufteilung trennt Konventionen (Palette, Hilfsfunktionen, Export) von Gestaltungsbegründung und Schritt-für-Schritt-Anleitungen. Das ist mehr Struktur, als man in einem reinen Skript-Archiv erwarten würde, und es ist der Teil, der sich am ehesten als eigenständig nutzbar beschreiben lässt.

Zwei Wege sind dokumentiert. Ohne Installation öffnet man das Repository im Agenten und verweist im Prompt auf scientific-figure-making/SKILL.md und scientific-figure-making/references/design-theory.md. Mit Installation legt man einen Symlink an, etwa für Claude Code mit mkdir -p ~/.claude/skills und ln -s "$(pwd)/scientific-figure-making" ~/.claude/skills/scientific-figure-making. Für Cursor und Codex nennt das README die entsprechenden Verzeichnisse ~/.cursor/skills und ~/.codex/skills. Danach muss der Agent neu gestartet oder seine Skill-Liste aktualisiert werden. Wer den Skill nur gelegentlich braucht, kann sich den Symlink sparen und den Pfad im Prompt angeben.

Was der Prompt-Template verlangt und was nicht

Das README liefert ein kopierbares Prompt-Template. Es fordert ein Skript unter einem Zielpfad, verweist auf SKILL.md, design-theory.md und api.md und nennt drei Konventionen beim Namen: apply_publication_style, make_*-Helfer und finalize_figure. Als Ausgabe sind PNG und PDF vorgesehen, und der Stil soll zum Repository passen. Platzhalter im Template sind Zielpfad, Datenbeschreibung und Dateinamen; die muss man selbst füllen.

Bemerkenswert ist, was das Template nicht festlegt. Es sagt nichts über Schriftgrößen, Farbräume oder DPI-Werte. Diese Details stecken laut README in api.md und design-theory.md, also in Dateien, die man im Repository lesen muss. Das ist ein bewusster Schnitt: Der Prompt bleibt kurz, die Konventionen liegen im Skill. Für Anwender heißt das, dass die Qualität des Ergebnisses davon abhängt, ob der Agent diese Dateien tatsächlich liest. Ein Agent, der nur den Prompt sieht, produziert ein Skript mit den genannten Funktionsnamen, aber ohne die dahinterliegenden Regeln.

Grenzen: keine Versionierung, keine Tests, keine Daten

Die offensichtlichste Einschränkung ist das Fehlen von Releases. Es gibt keinen Tag, an dem man sich festhalten könnte, und keine Angabe dazu, welche Matplotlib- oder NumPy-Version die Skripte erwarten. Wer das Repository in eine laufende Pipeline einbinden will, muss den Stand selbst pinnen. Das ist bei einem Vorlagenarchiv verkraftbar, bei einer Abhängigkeit nicht.

Der zweite Punkt betrifft die Daten. Die Skripte erzeugen Abbildungen aus Ergebnissen der jeweiligen Paper. Ob diese Zwischenergebnisse im Repository liegen, lässt sich aus dem Material nicht bestätigen. Wer ein figure_*-Skript unverändert ausführt, kann daher an fehlenden Eingabedateien scheitern. Das README gibt dazu keinen Hinweis, und das ist eine Lücke, die man vor dem Ausprobieren einplanen sollte.

Drittens die Lizenz. Die Metadaten melden NOASSERTION, das heißt, es wurde keine Standardkennung erkannt. Das README selbst enthält keine Lizenzangabe. Ob und unter welchen Bedingungen Code übernommen werden darf, lässt sich daraus nicht ableiten. Wer Abbildungen für eine eigene Publikation erstellt, sollte die LICENSE-Datei im Wurzelverzeichnis selbst prüfen und bei Unklarheit den Autor kontaktieren. Eine rechtliche Einschätzung ist an dieser Stelle nicht möglich und soll hier auch nicht gegeben werden.

Alternative: eine gestaltete Bibliothek statt kopierter Skripte

Wer wiederkehrend dieselben Diagrammtypen braucht und dabei nicht jedes Mal ein Skript anpassen will, ist mit einer gestalteten Plot-Bibliothek besser bedient. Der Unterschied liegt nicht in der Ausgabequalität, sondern im Vertrag. Eine Bibliothek bietet stabile Funktionssignaturen, dokumentierte Parameter und eine Versionsnummer, unter der sich Verhalten festhalten lässt. figures4papers bietet stattdessen lesbare Beispiele, die man kopiert und ändert. Der eine Ansatz skaliert über viele Paper hinweg, der andere über viele Diagrammtypen.

Ein zweiter Unterschied betrifft die Gestaltung. Eine allgemeine Bibliothek bringt Themes mit, die für viele Kontexte funktionieren sollen. figures4papers bringt laut README eine design-theory.md mit, die begründet, warum bestimmte Entscheidungen getroffen wurden. Das ist für Publikationen nützlicher, weil Zeitschriften und Konferenzen eigene Vorgaben machen. Wer allerdings eine Grafik in einem Web-Dashboard oder in einem wiederkehrenden Report braucht, wird mit einem Paper-spezifischen Skript nicht glücklich.

Wartung: ein Einzelprojekt ohne Release-Zyklus

Das Repository wird aktiv gepflegt, der letzte Push liegt nur wenige Tage vor dem Abruf. Es gibt jedoch keine Releases und damit keinen Anlass, von einem stabilen Stand auszugehen. Änderungen an den Skripten oder am Skill-Ordner erscheinen direkt auf main. Wer den Code über einen Symlink einbindet, bekommt diese Änderungen automatisch mit, ohne sie zu prüfen. Wer ihn kopiert, friert den Stand ein und muss selbst nachziehen.

Der Upgradepfad ist entsprechend manuell. Es gibt keine Migrationshinweise, weil es keine Versionen gibt. Bei einem Archiv dieser Größe ist das vertretbar, solange man die Skripte als Ausgangspunkt behandelt und nicht als Abhängigkeit. Der Skill-Ordner ist der Teil, der am ehesten von Änderungen betroffen sein dürfte, weil sich die Konventionen von Coding-Agenten schnell bewegen. Das README nennt für Cursor, Claude Code und Codex jeweils eigene Skill-Verzeichnisse; ändert sich eines davon, muss der Symlink neu gesetzt werden.

Redaktionelles Fazit

Sinnvoll ist figures4papers für Forschende, die bereits Matplotlib bedienen und eine Vorlage für Balken-, Radar-, Trend- oder 3D-Kugel-Darstellungen suchen: Skript aus dem passenden figure_*-Ordner kopieren, an eigene Daten anpassen, mit finalize_figure als PNG und PDF exportieren. Wer eine installierbare Bibliothek mit stabilem API-Vertrag braucht, sollte nicht darauf setzen, denn das Repository ist eine Sammlung persönlicher Skripte ohne Release. Vor der Übernahme zuerst die LICENSE-Datei im Wurzelverzeichnis prüfen, da die Metadaten NOASSERTION melden, und danach das gewählte figure_*-Skript gegen die eigene Matplotlib-Version laufen lassen.

Offizielle Quellen

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