# ppt-master ships as an agent skill, and its root requirements.txt is one include > ppt-master is a Python workflow that turns documents into native .pptx decks and is distributed as a skill for AI coding agents rather than as an application you install. The interesting parts are in the packaging: the root dependency file delegates to the skill, and the .env lookup reads the first file it finds and merges nothing. **hugohe3/ppt-master** — PPT Master turns documents or topics into natively editable PowerPoint decks with transitions, data-backed charts and audio narration from speaker notes. - Repository: https://github.com/hugohe3/ppt-master - Website: https://hugohe3.github.io/ppt-master/ - Stars: 57,003 · Forks: 4,511 - Language: Python - License: MIT - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/hugohe3-ppt-master ## The unit of installation is a skill directory, not a Python package There is no setup.py, no pyproject with an entry point, and no published package name for the tool itself. What sits at the root of the repository is a .claude-plugin/ directory, a skills/ directory, AGENTS.md, CLAUDE.md, a projects/ folder, an index.html landing page and a docs/ directory, which is the shape of something that gets installed into an agent rather than into a virtualenv on its own. The environment file makes that concrete. One of the four places image_gen.py looks for configuration is the skill install directory, given as ~/.agents/skills/ppt-master/.env, so an installed copy lives under the agent's own skills tree and carries its configuration with it. A clone instead reads from the repository root, which is a third path to the same settings. So there are two different installations with two different behaviours. A clone gives you a working tree you edit, and an installed skill gives you a copy under your home directory that your agent loads. Neither is a pip install of a tool you invoke, and the README's own navigation points at a Quick Start section, a live example viewer, an FAQ at ./docs/faq.md and a roadmap at ./docs/roadmap.md rather than at a command reference. ## The root requirements.txt is comments and one -r include requirements.txt at the root of the repository contains two install instructions in comments, one flag, and no package names at all: ```bash pip install -r requirements.txt # from repo root pip install -r skills/ppt-master/requirements.txt # from anywhere ``` The single real line is an include of the file inside the skill, and the comment above it explains why: the full list lives inside the skill so that installing the skill alone gives full capability. The second comment adds that update_repo.py fingerprints this file and its recursive -r/--requirement include tree, so a change anywhere in that tree is what the updater notices. Two consequences. An auditor reading the root file learns nothing about what gets installed, because the dependency names are one level down in a file the root does not show. And a version check against the root file is a check against a pointer, so the thing to compare is the tree it includes, which is what the fingerprinting step exists to do. ## The .env lookup reads the first file it finds and merges no keys The sample environment file is explicit about its own resolution order, and the important word is in the note above the list: only the FIRST existing file is read, and keys are NOT merged across files. The order is ./.env in the current working directory, then .env inside the skill directory, then .env at the repository root when running from a clone, and last ~/.ppt-master/.env as a user level config. That is a footgun with a specific failure mode. A .env file left in the directory you happen to be running from shadows your user level configuration completely, not partially. You change a key in ~/.ppt-master/.env, nothing changes, and the reason is a file three hundred lines away in the order of precedence. Process environment variables take precedence over the file, which adds a second place where a setting can be coming from. The other half of the file is the image configuration, and it marks IMAGE_BACKEND as required, naming openai, gemini, qwen, zhipu and volcengine as the recommended core backends. IMAGE_CONCURRENCY sets the maximum concurrent requests in --manifest batch mode, defaults to 3, halves automatically on a rate limit, and falls back to 1 as the serial case. Batch throughput is therefore bounded by whichever provider you configure, and the halving is what you see when that provider pushes back. ## IMAGE_API_KEY and IMAGE_MODEL stopped working, and the file still loads The sample environment file carries a short IMPORTANT block that reads like a migration note left in place. IMAGE_API_KEY, IMAGE_MODEL and IMAGE_BASE_URL are no longer supported, and provider specific keys should be used instead. Nothing in the file makes the old names an error, and nothing rewrites an existing .env for you. So a configuration written against the previous variable names keeps being read, keeps being parsed, and simply has no effect on the image step. The only place the change is written down is a comment in a sample file you may never open again after your first successful run. The failure you get is a missing key on a provider, which reads like a credentials problem and sends you to the wrong dashboard. Worth pairing with that: the same file documents the concurrency default and the auto-halving, so the parameters you can actually tune are narrow and documented, while the parameters that changed without a version bump are only in a comment. If you are upgrading an existing install, diffing the sample file against your own .env is the cheapest check available. ## Native shapes are a claim you verify by opening the .pptx in PowerPoint The positioning claim is specific: slide masters, native shapes, data backed charts and tables rather than flat text boxes, transitions and animations, audio narration produced from speaker notes, and support for your own .pptx templates. Every one of those is a property of the output file, not of the generator, and only PowerPoint can confirm which one you got. That is why the examples section tells you to download a .pptx and open it, calling that the fastest way to see what the tool can really do, and it is why the three showcased decks are described in terms of the file: a pixel art breakfast atlas with AI sprite sheets, HUD panels, Morph and 8 bit sound cues; a Transformer paper walkthrough with diagrams, native formulas, notes and animations; and a China Telecom results deck rendered on the company's own template with a native chart export. Those captions are claims about the artefact, which is the right level to make them. The captions also say every example is a single pass with no manual polish, which sets the expectation for anything you generate. If a result needs work, the work is on your side of the export, and the browser based example viewer is a preview rather than the file you would hand to a client. ## Three minor releases in eight days, and the last push was 2026-09-27 The release record is dense at the top end. v6.4.0 shipped on 2026-09-12, v6.5.0 on 2026-09-16 and v6.6.0 on 2026-09-19, and the last push to the repository was on 2026-09-27, so the tree is being worked on rather than parked. A six part version with three minors in a week is a fast cadence, and nothing in the repository suggests a long term support branch or a maintenance window for the previous minor. For a skill that lives in an agent's directory, that cadence is the operational fact to plan around. Whatever you install can be a different behaviour a week later, and the version that produced a deck you liked is not a version you can name and return to unless you pinned it yourself. The project's own answer to the question of where it is going is a roadmap document at ./docs/roadmap.md, and its answer to the question of what breaks is an FAQ at ./docs/faq.md. Licence and governance are the ordinary part: MIT, with a LICENSE file at the root and a badge linking to the licence text, plus CODE_OF_CONDUCT.md, SECURITY.md, CONTRIBUTING.md and a Chinese README_CN.md beside the English one, and separate English and Chinese sponsoring files. ## The sponsor block is five API relays with affiliate links, and it sits above the docs The first screen of the README is a sponsors table inside a collapsible block, naming Kimi, PackyCode, APIKEY.FAN, RunAPI and APIMart, with SPONSORING.md as the route to appear in it. Read the links and the structure of the arrangement is clear. Each is a registration URL carrying a referral parameter, and the text attaches a specific offer to each: a promo code for 10% off, up to 5% off on top-ups permanently, ¥7 in free credit, and per image pricing on the image platform. What is being sponsored is access to hosted models and hosted image APIs. That sits next to a positioning claim that generation runs on your machine with your data staying local and no platform or model lock-in. Both are true in different scopes, and the difference is the image backend. The pipeline is local, and the config file requires you to name a hosted provider, with openai, gemini, qwen, zhipu and volcengine as the recommended set. Whatever the deck's text was built from, the images in it come from whichever service you configured. The repository is also mirrored beyond GitHub, with a badge pointing at an AtomGit copy of the project and two more badges pointing at third party directories. For a user that is a redundancy path. For a contributor it is worth knowing that a mirror exists before filing an issue in one place and wondering why nothing happens. ## Conclusion Adopt ppt-master if you generate decks inside an agent workflow and can live with a hosted image backend, since the output is a real .pptx with native shapes and you can keep refining it in PowerPoint. Do not adopt it as a library you pin, because the root requirements.txt is a single include into the skill, no entry point is published, and three minor versions landed between 2026-09-12 and 2026-09-19. Before the first run, read docs/faq.md, delete any IMAGE_API_KEY, IMAGE_MODEL or IMAGE_BASE_URL lines from your .env because those names are no longer supported, and confirm which of the four .env locations applies to you, since only the first file found is read. ## FAQ ### What does hugohe3/ppt-master actually produce? A native .pptx rather than images of slides. The project describes slide masters, native shapes, data backed charts and tables, transitions and animations, audio narration generated from speaker notes, and support for your own .pptx templates. ### How do I install the ppt-master dependencies? From the repository root, run pip install -r requirements.txt. From anywhere, run pip install -r skills/ppt-master/requirements.txt. The root file contains only an include of the skill's file, because the full dependency list lives inside the skill. ### Which image provider does ppt-master use? image_gen.py reads an IMAGE_BACKEND value, with openai, gemini, qwen, zhipu and volcengine named as the recommended core backends. It takes provider specific keys only, since IMAGE_API_KEY, IMAGE_MODEL and IMAGE_BASE_URL are no longer supported. ### Why is my ppt-master .env file being ignored? The config lookup reads only the first file that exists and does not merge keys across files, checking ./.env in the working directory first, then the skill directory, then the repository root, then ~/.ppt-master/.env. A .env in your working directory therefore shadows your user level settings completely. ### Does ppt-master send my material to a third party service? The project says the workflow runs on your machine with no platform or model lock-in, and the image step is configured separately through a required IMAGE_BACKEND whose recommended options are hosted services including openai, gemini, qwen, zhipu and volcengine. ## Sources - [Official documentation](https://hugohe3.github.io/ppt-master/) - [Official README](https://github.com/hugohe3/ppt-master#readme) - [Project repository](https://github.com/hugohe3/ppt-master) - [Release notes](https://github.com/hugohe3/ppt-master/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hugohe3-ppt-master