paper2anything: five Claude Code skills that turn one PDF into five different artifacts

The problem is format count, not paper reading

Most researchers do not struggle to understand a paper they wrote. They struggle to produce the same content five times in five registers. A conference poster, a slide deck, a project homepage, a Xiaohongshu multi-image post, and a WeChat Official Account article share a source but almost nothing else: aspect ratios, reading order, tone, and length all differ. paper2anything treats that repetition as the target. The README frames the pack as covering "the main forms of paper dissemination" and organizes it as five independent skills, each with its own SKILL.md, so a user can install one and ignore the rest. The audience is therefore narrow and specific: people who already work inside Claude Code, who have a paper PDF in hand, and who need at least two of those five outputs. Anyone who needs one output is paying the install cost for four skills they will not trigger.

Five skills, five output contracts

The README's table is the clearest statement of scope. paper2slides produces a .pptx. paper2poster produces poster.html plus poster.png. paper2html produces a single index.html project homepage. paper2xhs produces xhs_post.json and xhs_post.md alongside a cover and figure images. paper2wechat produces wechat_article.md and wechat_article.html plus a cover. The trigger phrases are listed per skill and are plain English, for example "make slides from this paper" or "turn this paper into a webpage". That detail matters more than it looks. Because each skill is auto-triggerable through its SKILL.md, the trigger phrasing is the actual interface: there is no CLI subcommand to memorize, and no flag to set. The trade-off is that a vague request like "turn this paper into something" gives the model no signal about which of the five contracts to satisfy. The README does not describe a disambiguation rule, so it is fair to say the pack assumes you already know which artifact you want.

The extraction step is the load-bearing part

The README states that the install script checks a MINERU_API_TOKEN, and describes it as "used for paper extraction". It also marks it as required. That single line is the most consequential fact in the repository. Everything downstream (slides, poster, homepage, post, article) is generation from extracted paper content, so the quality ceiling of all five skills sits on the extraction step, and that step is delegated to an external service behind a token. Two things follow. First, the pack is not self-contained: without a valid token the pipeline has no documented starting point. Second, the README does not describe what happens when extraction is partial, when the PDF is a scan, or when the token is rate-limited. There is no fallback path described. If you are evaluating this for a workflow where PDFs arrive in unpredictable condition, that gap is the thing to probe first, not the visual quality of the generated posters.

Install: one script, one conda environment, two flags

The README gives a one-command install per platform: bash tools/install-linux.sh --create-env --shell-init on Linux, and the macOS equivalent. The script does three things according to the README: symlinks the five skills into ~/.claude/skills/, bootstraps a .env from .env.example if none exists, and checks the conda environment, system dependencies, and MINERU_API_TOKEN. The two flags are optional and separable. --create-env runs conda env create (or updates per environment.yml if the environment already exists), installs playwright chromium, and runs a pip self-check. --shell-init writes the .env auto-export into your shell startup file so new shells load credentials automatically. All five skills share one conda environment named paper2anything. For a partial install, the manual path is to symlink only the skill you want, for example ln -sfn "$(pwd)/paper2poster" ~/.claude/skills/paper2poster, then create the environment with conda env create -f environment.yml. The README's dependency table lists poppler-utils for PDF rendering and libreoffice for visual QA, both attributed to paper2slides, installed via apt on Linux or brew on macOS.

Where it is the wrong tool

The dependency table is worth reading as a scope statement rather than an install checklist. poppler-utils and libreoffice are both listed against paper2slides only. If that attribution is accurate, then the poster, homepage, Xiaohongshu, and WeChat skills do not depend on a local PDF renderer, which raises a question the README does not answer: how those four skills obtain page imagery, given that paper2poster is documented to emit a poster.png and paper2xhs is documented to emit figure images. The most plausible reading is that figure extraction happens through the same external extraction service, which loops back to the token dependency. A second limitation is the format list itself. Xiaohongshu and WeChat are Chinese-platform outputs, and the README ships a parallel README.zh-CN.md with an explicit instruction to keep the two in sync. That is a maintenance signal as much as a localization one. A third case: if your target is a LaTeX Beamer deck that matches an existing template, a .pptx output is the wrong primitive, and the README does not describe a template mechanism.

The alternative is a general PDF-to-deck converter

The obvious comparison is a standalone PDF-to-PowerPoint or PDF-to-Markdown converter, which typically runs locally, needs no API token, and produces one artifact deterministically. The difference in approach is where the intelligence sits. A converter applies extraction and layout rules to the PDF. paper2anything applies extraction to the PDF and then hands the content to a language model that writes the artifact, which is why the same source can become a poster and a WeChat article with different registers. That is also why the outputs are less predictable: a converter gives you the same deck structure every time, while a skill's output depends on the prompt and the model. Neither approach dominates. If you need reproducibility and no external credentials, the converter wins. If you need five registers from one source and you are already paying for Claude Code, the skills pack removes the rewriting work.

Licence, maintenance, and what to check before adopting

The repository is Apache-2.0, which permits commercial use and modification and includes a patent grant, with the usual requirements around preserving notices and stating changes; that is a summary of the licence family, not legal advice, and the LICENSE file in the repository is the authority. Maintenance cost is dominated by the shared conda environment rather than the skill code. All five skills resolve against one environment named paper2anything, so a dependency bump for one skill is a bump for all five, and the --create-env flag is documented to update an existing environment per environment.yml rather than rebuild it. The repository shows no releases retrieved, so there is no versioned artifact to pin against; the practical unit of upgrade is a git pull. The bilingual README adds a second maintenance surface, since the README instructs contributors to edit both files together. Before adopting, verify three things in order: that a MINERU_API_TOKEN can be obtained and that extraction succeeds on your own worst PDF, that the libreoffice and poppler-utils dependencies install cleanly on your platform, and that the skill's trigger phrase fires reliably rather than being shadowed by another installed skill in ~/.claude/skills/.

Editorial conclusion

Adopt it if you already run Claude Code and regularly need more than one dissemination format from the same paper, because the five skills share one conda environment and one extraction path. Skip it if you only ever need slides, or if you cannot obtain a MINERU_API_TOKEN, since the README marks that token as required and the pack has no documented fallback. Before committing, run the install script with --create-env on a machine where you can watch the conda solve, then generate one poster and open poster.png, because the README's own dependency table shows libreoffice is only needed for the slides skill's visual QA step, which means a broken poster render may not surface until you look at the image yourself.

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. QuZhan51496/paper2anything on GitHub
5. README