rw-consulting-ppt: the deck is a PNG, and the editable version is a second skill

Two sibling skills that install separately and do not overwrite each other

The repository contains two skills and the relationship between them is the first thing to understand.

One turns industry reports, meeting minutes, interview notes, and half-finished bullet lists into image-based consulting slides built around a proof object per page. The other takes a single slide image, a screenshot, or a page from an image-based presentation and turns it into a more editable PowerPoint file.

They are siblings in the same directory, they are installed separately, and they are triggered separately. The documentation is explicit that neither overwrites the other, and that if you need later editing you run the second one on the first one's output page by page, merging and checking multi-page results separately.

Installation is a copy into the assistant's skills directory, and the two directories are created as siblings rather than nested. On a Unix-like shell it is two target directories and two copies:

# macOS / Linux
mkdir -p ~/.codex/skills/rw-consulting-ppt ~/.codex/skills/astralow-for-editable-ppt
cp -R ./skills/rw-consulting-ppt/. ~/.codex/skills/rw-consulting-ppt/
cp -R ./skills/astralow-for-editable-ppt/. ~/.codex/skills/astralow-for-editable-ppt/

A Windows PowerShell equivalent is given using directory creation and recursive copy commands instead. The requirement that they be peers rather than one inside the other is what stops the second install from clobbering the first.

The runtime split matters too. The image-to-editable skill needs Python 3.10 or newer plus two libraries, installed from a requirements file in the skill directory, and the documentation tells you to use the one inside your install directory if you copied only the skill folder rather than the whole repository.

The default PowerPoint file has one image per page and no text objects

The output shape is stated precisely, and it is not what most people expect from a slide generator.

Each page is produced as one complete 16:9 image. A set of those images can then be packaged into a PowerPoint file, and the documentation is unambiguous about what that file contains: one full image per page, with no editable text objects at all.

The default output directory listing makes the pipeline visible. Individual slide images in numbered order, a contact sheet for scanning the whole deck at once, the packaged image-only presentation file, and a notes file recording what the run did.

So the argument for the approach is not that an image deck is better than an editable one. It is that a consulting page with a funnel, a path diagram, a landscape grid, or a risk bridge is a designed artefact, and re-deriving it from a text box and a shape tree every time someone moves a label is a large amount of work for a change that will be thrown away. Rendering the design directly means the layout is what the designer intended, and the cost is paid later if somebody needs to edit.

Which is why the second skill exists, and why the documentation is careful to say the actual extent of editability is whatever the final file and the notes about partial images say, rather than a blanket claim.

The gate is one or two sample pages, and there is a list of reasons to reject them

The workflow has a hard stop between planning and production, and the planning half is longer than most people expect.

It starts with a preference alignment covering six things, confirmed before anything is produced: who the audience is and how the deck will be used, whether it is presented live or read on its own, how many pages, the information density, the visual style and accent colour, and the output format. Then the raw material is turned into a production input package of context, the core question, a working thesis, a storyline, page-level inputs, and open questions. The stated goal of that step is not to produce images but to work out what you are going to say.

A deck blueprint then defines, for every page, its title, its governing message, its proof object, its visual mode, and any uncertain evidence that needs filling in or flagging. That blueprint requires your confirmation, and without it the workflow does not proceed to samples.

The gate itself is one or two representative pages, written as detailed briefs first. The rejection criteria are specific rather than aesthetic: looking like an ordinary editable template, having pretty cards with no proof object, having the title, the numbers, and the bottom-line conclusion competing with each other, having too little text to read without the presenter, being one colour throughout, and having no working visual link between the evidence and the conclusion. When a sample fails, the instruction is to rewrite the brief or the prompt rather than to batch anyway.

Two more guardrails are worth naming. One claim per page, so the title, subtitle, proof object, and bottom takeaway cannot fight. And density preservation, which explicitly forbids making a standalone report page into an empty poster for the sake of looking clean.

Verification means desktop PowerPoint on Windows, and nothing else counts

There is a line in the documentation that will save you from shipping an unverified deck.

Actual rendering and editing verification requires Windows desktop PowerPoint. Other environments can build the file, but the documentation says plainly that such a result cannot be marked as Office-verified.

That is a stricter position than most tooling takes, and it makes sense here. A file assembled from images and text boxes can be structurally valid and still render differently in the application that will open it, so a build on a non-Windows machine is a build you have not actually looked at.

The second skill is the one this bites hardest, because its whole job is producing a file that somebody will edit. Its output per page is described as three things: the editable file, an actual render preview, and a short report. The report is where the honesty is expected to live, since the documentation says the actual editable extent is whatever the final file and the notes about which parts remain images indicate.

Two other environment facts are stated in the same area. One model must be chosen by the user, and the skill will not switch it for you. And if you copied only the skill folder rather than the whole repository, you install dependencies from the requirements file inside the install directory instead of the one at the repository root.

The conversion rewrite is a measured claim on a single page

The newer version of the conversion skill is presented with a number, and the number is scoped.

The stated result is that in a single-page test, conversion went from something over ten minutes under the old approach to about three minutes, which is roughly a fifth of the previous time. Compared with running the model with nothing else around it, both the elapsed time and the credit consumption estimated at a standard rate dropped by about ten percent.

Three things are worth noticing about how that is framed. It is one page, not a deck. It is a comparison against a specific baseline, the bare model run, not against other tools. And the credit figure is explicitly an estimate at a named rate, which is the honest way to state a cost claim without pretending to have measured billing.

What changed underneath is described as a simplification for that model, with drawing, rendering, and checking tools provided rather than a single multi-page controller from the older design. The base tools process one page at a time, and multi-page results need to be merged and checked separately, which is a cost the documentation names rather than hides.

The intent behind the rewrite is stated as keeping text, numbers, and the main structure natively editable where possible, while allowing complex visuals to keep partial crops. So the goal is partial editability rather than a promise of a fully native page.

Upgrading from the older skill is an instruction block, not a script

There is a dedicated upgrade document, and the procedure it describes is a paragraph of natural language to hand to the assistant rather than a command.

The block does five things. It asks the assistant to upgrade an installed older skill to the newer one, sourcing it from the repository directory. It requires backing up the old skill outside the skill search directory before installing the new version and any missing dependencies. It says that if the new version is already installed, update it rather than installing again, so the operation is idempotent. It instructs the assistant to keep historical presentations and output files. And it tells it not to overwrite the sibling skill.

Afterwards, the new one is invoked by name, and there is a caveat: if the current session does not recognise the new version, start a new task.

That last point is the one that trips people up, and the reason it appears in the documentation is that a skill directory copied into a search path is read at session start. Copying new files into it does not reload the assistant's view of what skills exist. The upgrade succeeds and the old name keeps resolving until you open a new session.

The repository also carries a release checklist alongside the upgrade guide and a changelog, which is a reasonable amount of process for a project whose install is a file copy.

Editorial conclusion

This suits someone who has a pile of industry reports and meeting notes and no storyline, and who would rather approve one sample page than review thirty generated slides. It is a poor fit if you need a deck you can edit natively on every page, because the default output is images and the documentation rules that case out explicitly, and a poor fit if you are not on Windows with desktop PowerPoint, since that is the only environment where the rendered output can be called verified. Before you install, check three things: that you are willing to run the two skills separately, since they are siblings that do not overwrite each other and the second only runs on the first's output; that you can choose the model yourself, because the skill will not switch it for you; and which of the two you actually need, because the first needs no Python at all while the second needs an interpreter and two libraries. There are no GitHub releases and the last push was 2026-09-29.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Pikapika260214/rw-consulting-ppt on GitHub
4. README