slide-maker: a source-traced PPTX generator that runs inside Codex and Claude Code
Turn papers, code, and docs into presentation-ready, natively editable PPTX in Codex / Claude Code. Native charts and equations, speaker notes, click-build animations, and an independent critic review before delivery.
At a glance
- What is it?
- slide-maker is an MIT-licensed Python skill that turns a paper, a repository, a document, or a bare topic into a natively editable PowerPoint file, using a small set of specialized agents plus a separate critic pass. The interesting part is not the export format. It is the constraint that every number and figure has to trace back to the supplied material.
- Who is it for?
- Adopt slide-maker if you already work inside Codex or Claude Code and the deck has to survive scrutiny: a thesis defense, a lab meeting, a paper talk, a metrics readout where someone in the room knows the real number. Skip it if you want a share link, a hosted editor, or a browser-based collaborative canvas, because the README states plainly that it produces a file and runs locally.
- 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 1 day 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 failure mode slide-maker is built against
The README names its target directly: the tool that expands a topic into slides and invents a statistic to fill the space. It cites one popular assistant printing 43 percent growth where the real figure was 12 percent. Whether or not that specific number is representative, the class of error is real and it is the one that ends a talk badly. A fabricated figure on a slide is not a cosmetic defect. It is a claim you now own in front of an audience that may include the person who produced the original data.
So the product promise is narrow and testable. Every number and figure in the deck traces back to your material. The README states that slide-maker reads your paper, repo, or doc, and that when you have no source it researches the topic instead. That second path is where the guarantee weakens, and the documentation does not spell out what sourcing discipline applies to researched content. If you are generating from a topic alone, treat the traceability claim as applying to whatever the research step returns, not to a source you supplied.
The audience is correspondingly specific. This is for people whose deck is theirs to defend: a thesis defense, a lab meeting or paper reading, a method overview, an experiment report. The template gallery leans the same way, with a Lab Meeting / Paper Talk direction described for paper reading and experiment reports. If your deck is a sales pitch where nobody will check the numbers, the whole design is overhead.
How the pipeline is actually structured
The README describes a small team of specialized agents rather than one prompt. The sequence it gives is: read the source, plan the story, design each slide around that story, build the .pptx, then run an independent review. Each stage has a distinct output that feeds the next, which is why the review step can be sized by the user after seeing the first render rather than being fixed at the start.
The design claim worth examining is that slides are composed one at a time against the content, not filled into a stock layout. That distinction matters because it changes where the failure surfaces. A template-fill tool fails by producing slides that look wrong. A compose-per-slide tool fails by producing slides that look fine individually and do not cohere as a narrative. The critic pass is positioned as the check on both, and the README is explicit that it is a separate model rather than the author grading its own work.
Output is a native .pptx. Text boxes, shapes, native charts and equations remain click-to-edit objects, and the README states nothing is flattened to an image. It also calls out the competing behaviour: some export tools quietly convert a portion of slides into uneditable pictures. That is a verifiable claim in the sense that you can open the file and click on things, which is the right way to check it.
The canvas story is broader than 16:9. The same skill recomposes to 4:3, square 1:1, rednote 3:4 cards, 9:16 story covers, and A4 print one-pagers, each with its own safe zones and layout logic. Treat that list as a claim about supported output sizes, not as evidence that every template has been tuned for every aspect ratio.
Installation runs through the agent, not a package manager
This is the part that trips people who skim. slide-maker is distributed as a skill for Codex and Claude Code, not as a pip-installable library you import. The README's distribution surface is a set of skill directories: Tencent SkillHub, Coze, ClawHub, and a ChatGPT GPT Store listing. The primary language is Python and the repository is on GitHub under addsumtech/slides_maker, but the documented entry point is the agent itself.
There is also a zero-install path. The README offers the slide-maker (addsum studio) GPT in ChatGPT for people who do not want to set anything up. That is a real convenience and also a different trust boundary, since your source material leaves your machine in that mode. The README's own limits section says there is no zero-setup cloud, which reads as a statement about the local skill rather than about the GPT listing.
A practical check before adopting: confirm which install path your agent actually supports and whether the skill resolves against the repository's default branch, main. The README does not document a version pinning mechanism, and the release cadence is fast enough that this matters. Three releases landed inside three weeks: v5.1.0 on 2026-08-24, v5.2.0 on 2026-08-30, v5.3.0 on 2026-09-03. If you need a deck to reproduce identically six months from now, you will be pinning against something the documentation does not currently describe.
The critic pass is the design decision to argue with
Most generators treat quality control as a prompt instruction. slide-maker makes it a separate stage with its own model, and the README frames it as adversarial: the critic tries to break the deck by looking for cramped layout, weak contrast, and numbers that do not match the source, then sends fixes back. The user chooses how hard to run it, or skips it, after seeing the first render.
That ordering is the smart part. You cannot judge how much review a deck needs until you have seen one. Making the intensity a post-render decision avoids the usual waste of running heavy review on a deck that was already fine.
It is also where the cost lives. A second model reading every slide, cross-checking figures against source, and iterating on fixes is not free in tokens or in wall-clock time. The README does not publish a cost estimate, and I would not trust one if it did, since it depends on deck length and how much source material you feed in. What you can reason about is the shape: the critic scales with slide count and source size, and the user controls it. Budget for the review step as a second pass over the whole deck, because that is what it is.
The claim that the critic is not the author model grading its own homework is the one to verify in practice. The README asserts separation; it does not document which models are used or how they are kept independent. If your use case depends on genuine adversarial review, that is an open question worth resolving before you rely on it.
Where slide-maker is the wrong tool
The README is unusually direct about its limits, and they are worth taking at face value. No zero-setup cloud. No share links. No animated web backgrounds. It makes a file, run locally, that opens and edits in real PowerPoint or Keynote.
That rules out a set of workflows. If your team collaborates in a browser on a shared deck, slide-maker produces an artifact you then have to distribute yourself. If your deliverable is a link someone can open on a phone without downloading anything, this is not it. If you need motion design or animated backgrounds, the output is a static .pptx with, per the release notes, click-build animations as a supported feature. That is a PowerPoint-native build sequence, not web animation.
There is a second category of mismatch. The whole value proposition rests on having source material worth reading. Feed it a topic with no source and you have removed the constraint that makes it different from any other generator, while keeping the multi-agent overhead. The README positions topic-only generation as a supported mode, and it is, but it is the mode where the argument for choosing this tool is weakest.
The release history also suggests a moving target. v5.3.0's title references four tags that erased each other, and v5.2.0's references registers that build their look. Those read as internal model changes rather than user-facing features. Rapid iteration on the composition logic is good for output quality and bad for anyone who needs byte-stable regeneration of an old deck.
What it is not: the alternative it is implicitly arguing against
The obvious comparison is Gamma, which the README never names but clearly has in view when it says most AI-PPT tools race to look pretty in seconds. The difference in approach is structural rather than cosmetic. Gamma-style tools optimize for a fast, good-looking result from a short prompt, and their export path often rasterizes parts of the deck on the way out. slide-maker inverts the priorities: slower, source-grounded, and natively editable all the way down.
If you want a deck in ninety seconds from a one-line prompt to send to a colleague, Gamma is the better fit and slide-maker is the wrong purchase of your time. If you want a deck where the chart on slide seven is a real editable chart bound to numbers from your paper, the two tools are not solving the same problem.
The other comparison point is the plain workflow: open PowerPoint, paste your content, format it. That is genuinely faster for a short deck and requires no setup. slide-maker earns its overhead on decks with real source material, multiple figures, and an audience that will check the numbers. Below that threshold, the multi-agent pipeline and the critic pass are cost without return.
Maintenance, licensing, and what to check before you commit
The licence is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is a permissive licence and it is the same one used by most tooling in this space, so it is unlikely to be the deciding factor. It is not legal advice; if you are embedding this in a product, have someone read the LICENSE file rather than this paragraph.
Maintenance looks active. The last push is 2026-09-08, five days after the v5.3.0 release, and the repository is not archived. The version numbering is at 5.x, which for a project this young implies a lot of iteration. The practical cost of that is upgrade churn. If you pin to a version, you are on a branch the maintainers have already moved past. If you track main, your decks may change shape between runs for reasons that have nothing to do with your source.
The repository describes itself as a skill rather than a library, so there is no documented public API surface to depend on. That lowers the integration cost and raises the coupling to the agent runtime. A change in how Codex or Claude Code loads skills is a change to your pipeline, and it is not something this project controls.
What to verify first, in order: download one of the twelve template decks as a .pptx from slides.addsum.top and open it in your own PowerPoint or Keynote to confirm the native-editability claim on your machine. Then run one real deck from your own source material and check whether the critic catches a figure you deliberately mismatched. That single test tells you more about whether this fits your work than any description of the agent pipeline.
Editorial conclusion
Adopt slide-maker if you already work inside Codex or Claude Code and the deck has to survive scrutiny: a thesis defense, a lab meeting, a paper talk, a metrics readout where someone in the room knows the real number. Skip it if you want a share link, a hosted editor, or a browser-based collaborative canvas, because the README states plainly that it produces a file and runs locally. Before committing, download one of the twelve template decks as a .pptx from slides.addsum.top and open it in your own PowerPoint or Keynote, then check whether the critic pass is something you want to size after the first render or skip entirely.
Community notes