# ppt-image-first builds decks as page images inside a PPTX > ppt-image-first is a workflow skill for coding agents that turns a vague request for a presentation into a planned deck by generating whole page images with GPT Image 2 and dropping them into a PPTX container. The trade is explicit in the documentation: the result looks finished and is not editable element by element. **NyxTides/ppt-image-first** — PPT image-first skill for Codex/Claude Code/Opencode CLI - Repository: https://github.com/NyxTides/ppt-image-first - Stars: 1,226 · Forks: 89 - Language: Python - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/nyxtides-ppt-image-first ## A skill that starts with a conversation, not a form ppt-image-first is a PPT skill for Codex, Claude Code and Opencode CLI, and the readme states its position immediately. It is a conversation-first, image-first workflow that takes a vague presentation request and advances it in stages into a content base, a style preview, a final plan and an executable generation flow. What it is not is as informative as what it is. It is not the kind of skill that makes the user fill in a pile of parameters or that assembles pages from a template. It is a staged, proposal style workflow: understand the requirement, build the content base, produce real previews, allow the style to be pushed back and forth, and only then lock and generate. The stated reason is a diagnosis of what goes wrong with other PPT workflows, in two directions. One is being too templated, which looks tidy but does not fit the content and reads as generic. The other is being too shallow, which looks like a presentation but has no narrative or depth capable of supporting a report. The four principles that follow are the design. The front conversation stays light and does not drag the user into a long questionnaire. If the material is thin, the content base is filled in before style is discussed. Style confirmation depends on real preview images rather than text descriptions. And the final page visuals go the image-first route instead of being patched up afterwards with overlays. The audience is whoever asks for a deck: a student preparing a defence, a researcher giving a progress report, a team presenting a product or a proposal, someone building training material. The repository is licensed Apache 2.0, and the readme acknowledges the Linux.do community for spreading open source work. ## Image-first means your slides are pictures in a container The output mode is stated in a note that anyone evaluating this project should read first. The default is image-first. The workflow uses GPT Image 2 to generate the whole page visual, and then puts those page images into a PPTX container for delivery. It is explicitly not a fully editable PPT generator that draws text boxes, shapes and charts one by one as PowerPoint objects. The result is closer to a high completion visual presentation: suitable for presenting, for reporting, and for further image-level retouch, but the text, graphics and decorative elements inside a page are usually not editable item by item like native PowerPoint elements. That single sentence decides who should use this and who should not. If the deck is a finished artefact that people look at, the image-first route buys visual consistency that a shape-by-shape generator cannot easily match, because the model composes the whole page as a single image. If the deck is a working document that a colleague will edit on Monday morning, this is the wrong tool, and no amount of workflow quality changes that. The related decision is that the workflow does not treat the generated image as a background to be rescued. The readme says explicitly that the approach is not patch-overlay-driven, meaning it does not default to using the image as a backdrop and then patching on titles, numbers, labels and captions afterwards to save the page. That is a coherent position, and it is also a bet: if the model renders a wrong number in the image, there is no text box to fix. The workflow also assumes a 16:9 default aspect ratio unless the user asks for something else, and the readme insists that preview pages must be content-bearing rather than empty shells or placeholders. ## Fourteen steps, and only three questions at the style boundary The workflow is enumerated in full, and the numbering is instructive because the gaps are the interesting part. There is a lightweight intake, then a baseline judgment, then requirements confirmation. Then a content base before style, which produces content_report.md, then a style boundary alignment, then several style direction previews, then optional style refinement, then style confirmation, then a style inversion confirmation, then the planning files, then a pre-generation confirmation, then a choice of generation branch, then a review and retouch loop, and finally the export. The stage detail is worth reading. Stage 1 collects only the essentials: the purpose, the audience, a rough page count or duration, the documents you already have, and a real identity anchor such as a school, company, laboratory, group, course or brand. It then outputs a short baseline judgment and stops at requirements confirmation. Stage 1.25 is where the content base is built if the user has not supplied report-like material. The purpose is to give a thin topic a presentable narrative, to turn scattered material into something that can be expanded, to stop the preview pages from being empty shells, and to give the later planning files a real source. Stage 1.5 asks three short questions and only three: whether the overall look is bright, dark or in between, whether the route is conventionally professional or clearly stylised, and how many directions to look at this round. That is the entire style negotiation, and it is the part most likely to surprise anyone used to design questionnaires. Stage 2 then produces several style directions with real preview images, covering a homepage, a table of contents page and a body page, and Stage 2.5 is where a nearly right direction can be pushed further instead of being forced to a decision. ## Style inversion: treat the chosen preview as evidence Stage 2.75 is the most distinctive idea in the workflow, and it is the one worth borrowing even if you use a different tool. Instead of asking the user to describe what they want, the workflow takes the preview image the user finally selected and treats it as evidence, working backwards to infer which stable features the user actually likes. Then it sorts them into three categories: features that should clearly be carried forward, features that had a good effect but need confirmation as to whether they should be extended across the whole set, and features that only happen to hold in this particular image and should not be locked in. That last category is the one that matters. A user who picks a preview is usually responding to the whole composition, and some of what they liked is a property of that one page rather than of the style. Locking the accidental parts produces a deck where every page is a variation of a single attractive accident, and the drift is invisible until the deck is eighteen pages long. Stage 3 then turns the confirmed style into three planning files, in order. design_spec.md holds the global rationale, the direction and the continuity constraints for the whole deck. slide_blueprint.md defines each page's intent, its content payload, its visual strategy and what it carries. And spec_lock.md is the execution constraint file, locking what may change, what may not, which content must not be invented and which strategies the later generation is allowed to use. The readme insists that the multiple confirmation points are deliberate design and not redundancy, and that the review stage belongs to the main flow rather than being bolted on at the end. For an agent workflow, that is a defensible position: an agent that has been wrong about your intent for forty minutes is expensive, and a confirmation gate is cheaper than a regeneration loop. ## Three shells and four artefacts ship with the skill The repository layout is the whole skill, and it is small enough to read in one sitting. There is SKILL.md, the two readmes, a references directory with workflow.md, conversation_framework.md and preview-flow.md among others, a templates directory holding the four reference documents content_report_reference.md, design_spec_reference.md, slide_blueprint_reference.md and spec_lock_reference.md, and an assets directory with three shell directories. There are also docs, scripts and a templates tree, and the primary language of the repository is Python, which is where the scripts live. The three shells are the interactive parts of the workflow. assets/preview_shell/index.html is for comparing style previews, assets/candidate_picker_shell/index.html is for choosing between multiple candidate images, and assets/review_shell/index.html is for the review and retouch pass. The readme is unusually directive about them: they are part of the workflow, and replacing them with homemade pages is not recommended. That recommendation is a design decision with a reason behind it. A shell is where the human and the agent meet, and the point of this skill is a specific interaction shape: show a small number of real previews, let the user react to images, and keep the agent from asking for a design brief in words. If you swap in a generic page, you lose the one place where that interaction is designed to happen. The four artefacts are the persistent outputs, and they are what make the workflow resumable. content_report.md is the content base, generated before style when the material is thin. design_spec.md, slide_blueprint.md and spec_lock.md are the planning layer, produced in that order, and spec_lock.md in particular is the file that tells the generation stage what it is not allowed to invent. ## The cost is the confirmation loop and the review stage Nothing in this workflow is free, and the two costs are visible in the documentation rather than hidden. The first is the confirmation loop. There are confirmation points at requirements, at style, before generation and during review, and each one is a round trip with the user. A user who wants a deck in ten minutes will find this slow, and a user who wants a deck that matches their intent will find that skipping a gate costs more. The workflow is designed for the second user, and the readme says the multiple confirmation points are deliberate. The second is the review and retouch stage, which is described as not optional. After the first complete result, the workflow does not treat it as finished. It enters a dedicated review and retouch process, using the review shell by default, and if the user is not satisfied the structured feedback is copied back into the conversation to continue the revision. So the number of image generations is a function of how many rounds of feedback the user has, and for a long deck that cost multiplies per page. There is also the dependency on an image model, specifically GPT Image 2, for the page visuals. The workflow is written around it, and a project that wants a different image model, or a local one, would be working against the grain of the reference documents. And the audience for all of this is set out in the readme: defence presentations, research reports, project reports, product introductions, roadshow decks, training material, proposal decks and internal review presentations. The recurring condition is that the user has only a topic or scattered material, needs the content solid before the style, wants to see real previews before committing, and needs the final output to inherit the visual logic of the preview that was approved. ## Conclusion ppt-image-first is worth adopting if your slides are for presenting, for a defence, for a review or for a pitch, and you care more about a coherent visual language than about being able to reopen the file and move a text box. It is the wrong tool if the deck has to be edited by other people afterwards, if the content must stay selectable and accessible, or if your organisation produces slides from a template that a human maintains. Before you use it, decide who owns the deck after delivery, and note that the project is licensed Apache 2.0, has no GitHub releases, and was last pushed to on 2026-05-08. ## FAQ ### What is ppt-image-first and what does it do? It is a PPT workflow skill for Codex, Claude Code and Opencode CLI. It takes a vague presentation request through a staged conversation that produces a content base, real style previews, planning files and a generation pass, ending in an exported PPTX. ### Is the PPTX produced by ppt-image-first editable? Not in the usual sense. The default output is image-first, so GPT Image 2 generates the whole page visual and those images are placed in a PPTX container. The readme says the result is closer to a high completion visual deck, and that the text, graphics and decorative elements inside a page usually cannot be edited item by item like native PowerPoint elements. ### What are the four planning artefacts in ppt-image-first? content_report.md is the content base written before style when the material is thin, design_spec.md holds the global rationale, direction and continuity constraints, slide_blueprint.md defines each page's intent, content payload and visual strategy, and spec_lock.md is the execution constraint file that locks what may change and what must not be invented. ### What are the three built-in shells in ppt-image-first? assets/preview_shell/index.html for comparing style previews, assets/candidate_picker_shell/index.html for choosing between multiple candidate images, and assets/review_shell/index.html for the review and retouch pass. The readme states they are part of the workflow and recommends against replacing them with homemade pages. ### When is ppt-image-first the wrong tool? When the deck has to be edited by other people after delivery, when the text must stay selectable and accessible, or when your organisation builds slides from a template that a human maintains. The image-first output cannot be edited element by element, and the readme is explicit about that trade. ## Sources - [Issues](https://github.com/NyxTides/ppt-image-first/issues) - [License: Apache-2.0](https://github.com/NyxTides/ppt-image-first/blob/master/LICENSE) - [NyxTides/ppt-image-first on GitHub](https://github.com/NyxTides/ppt-image-first) - [README](https://github.com/NyxTides/ppt-image-first/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nyxtides-ppt-image-first