academic-pptx-skill overrides a default rather than adding a capability, and its PDF is not in its own file list

It replaces a default style rather than adding a capability

The framing on the page is unusually blunt, and it is about substitution.

The skill overrides the assistant's default design-forward presentation style and replaces it with communication-first standards for academic and analytical contexts. So the problem being solved is not that the assistant cannot make slides. It is that the assistant makes slides the way it makes slides, and the result looks like a product pitch rather than a research talk.

That framing has an immediate consequence. This is not a standalone generator, and the page says so directly: it works alongside a built-in skill from the assistant's vendor, that one handling the technical file generation while this one handles content, argument structure and design standards. Two skills, one file.

So the deliverable you get depends on a second component you did not install and cannot inspect from here. If the built-in file generation changes its behaviour, this skill's rules still apply to the content and the output still changes shape.

The activation is also implicit. The page says to ask naturally, gives three example requests, and states that the assistant detects the academic context, loads the skill automatically, and applies all guidelines before generating any slides, with no special instructions needed. That is convenient and it is also a decision you do not make. A request that is not clearly academic may not trigger the skill at all, and nothing tells you when it has been applied.

The scope it claims is four presentation types: conference talks, seminar slides, thesis defenses and grant briefings.

Seven rules, and the ghost deck test is the one you can apply without the tool

The standards are seven items, and they are specific enough to check by hand.

The first is the action title: every slide title is a complete sentence stating the takeaway, not a topic label. The second is that the deck is a logical argument in three parts, situation, then complication, then resolution, rather than a collection of independent slides.

The third is the test that ties them together. It is called the ghost deck test, and the condition is that the action titles alone, read in sequence, should tell the full story. Take the titles away, leave everything else, and the argument should survive.

That is the genuinely useful item here, because it is a check you can run on a deck you already have, without this skill, without the assistant and without regenerating anything.

The fourth rule is exhibit discipline: one exhibit per results slide, with the key finding annotated directly on the chart rather than left for the audience to infer from a caption.

The fifth is citation standards: an in-text citation on every borrowed figure, and a references slide at the end.

The sixth is the last slide. It must be a conclusions slide that stays on screen during questions, and explicitly never a thank-you slide and never a blank one. That is a small rule with a large effect on how a defence feels, because the slide the audience is looking at while they are forming a question is the one you control.

The seventh is design, and it is covered in its own section because it is the part that most directly contradicts the default being replaced.

Three colours, one font, white backgrounds, and no decorative icons

The design rule is a single bullet and it is the most concrete reversal of the default in the whole skill.

Minimal, communication-first design means white backgrounds, a single sans-serif font, three colours at most, and no decorative icons.

Every one of those is a subtraction. The style being replaced is design-forward, which is exactly the set of habits that add a coloured background, a theme, an icon next to every bullet and a second typeface for emphasis. Stripping all four out is not a taste preference, it is a different theory of what a slide is for: a support for what the speaker is saying rather than an object that has to look designed while nobody is talking.

The three-colour limit is the sharpest constraint, because it is countable. A deck that needs a fourth colour to distinguish two more categories has an information design problem, and the limit surfaces it.

The no-icons rule is the one most likely to feel extreme to someone who presents from bullet points, and it is also the one most consistent with the action title rule. An icon is a topic label in pictorial form: it says what the slide is about without saying what the slide concluded.

Worth noting how little else is prescribed. There is no template, no grid specification, no guidance on charts beyond annotating the finding on the chart itself, and no font recommendation beyond a single sans-serif. The rules constrain what must be absent more than what must be present, which is unusual for a design guideline and is presumably deliberate.

Installation is a zip upload that needs a capability switch enabled first

There are four steps and one requirement, and the requirement is the one to read first.

Code execution and file creation have to be enabled in the settings, under a capabilities section. If they are not, the skill uploads and then does nothing useful, because the whole point is that it drives a script to produce a file.

The steps themselves are the simplest possible distribution. Download the repository as a zip, through a download link at the top of the code menu. Then, in the web interface, go to the customize section and find skills. Upload the zip. Confirm the skill appears in the list and is toggled on.

There is no package manager, no command line and no repository to clone. That is the trade: you cannot inspect what is in the zip before uploading it, and you cannot update it except by doing the whole thing again with a new download.

The four files that get uploaded are named in the documentation, and the entry point is the one that matters if you want to read before you install. The entry file holds the routing logic and the design standards. A second file holds the argument structure, the action titles, the citations and the deck architecture. A third holds per-slide-type implementation patterns, and it is the only one containing code, written in a JavaScript presentation library.

So the upload is small: a routing file, a guidelines file, a patterns file with code, and the readme.

The documented file structure has four entries and the repository has six files

The file structure block in the documentation is a tree, and the tree in the repository does not match it.

The documented structure lists four things: a directory containing the entry file, the content guidelines, the slide patterns, and the readme. That is the whole of the skill as documented.

The actual top-level entries are six: a licence, the readme, the entry file, the content guidelines, the slide patterns, and a PDF.

The fifth file, the licence, is unremarkable and expected. The PDF is not, for two reasons. It is the artefact the opening paragraph advertises, since the page describes itself as a skill plus a basic PDF summary of general advice that does not require the use of the assistant. And it is the one file in the repository whose name is a sentence rather than a role.

So a reader who follows the structure block to understand what they are about to upload will not know the PDF is inside it. That matters more than a missing line in a tree would usually matter, because the PDF is the piece someone might want instead of the skill: it is explicitly described as usable without the assistant at all.

The other structural detail is the language. The file that carries the implementation patterns contains code in a JavaScript presentation library, and the repository's primary language is recorded as none, which is consistent with a repository that is almost entirely prose plus one code file.

Four files of rules, one file of code, one file nobody would expect to find there.

The PDF carries an author's initials, a model name and a version in its filename

The one undocumented file has a filename that says more than most READMEs do, and it is worth reading it as a fact about the project rather than as a naming quirk.

The name consists of a descriptive phrase about academic presentation best practices, then two initials, then a phrase saying it was built with the assistant, then a version number of two, then a year of 2026. Underscores between the parts, a file extension, committed to the repository root.

Three things follow from that name. There is a person attached, or at least a pair of initials, which means this is one author's compilation rather than a community document. It was produced by the same assistant the skill configures, so the PDF is an output of the tool it documents. And it is on a second version, which means a first version existed and was not kept in this repository.

The README's own description of the file is much more modest than the filename suggests. It calls it a basic PDF summary of general advice, and notes twice that it does not require the use of the assistant.

That combination is the interesting part. The filename implies a versioned, authored, tool-generated artefact promoted in the repository's opening line. The description calls it a basic summary. And the file structure block, which is the part a person reads to know what they are downloading, does not mention it.

If you want the rules without installing anything, that PDF is the route, and it is the only part of this repository that works with nothing else.

The provenance is a business book, one journal article, and community feedback

The background section names four sources, and they are of very different kinds.

The first is a business writing book, cited for two specific things: the structured argument and the action title. So the skeleton and the title rule are not this author's invention, they are imported wholesale from a well known piece of consulting practice.

The second is a 2021 journal article in a computational biology publication, titled as ten simple rules for effective presentation slides. That is a peer reviewed source, and it is the only one of the four that is.

The third is practice rather than writing: standard consulting and academic presentation norms, with a specific consultancy named and conference conventions.

The fourth is the most revealing. The list credits community feedback on the assistant's default presentation behaviour in professional contexts. In other words, part of the reason these rules exist is that people were unhappy with what the tool produced, and someone turned that into a specification.

So three of the four sources are established practice and the fourth is a reaction to observed tool behaviour. That is a reasonable basis for a style guide, and it is also a different kind of project from a library: there is no code to test, no API to keep stable, and no behaviour that can be verified except by looking at a deck afterwards.

The distribution is a zip upload with no versioning, and the last push to the default branch is recorded as 2026-07-14. The repository is not archived, and the licence is MIT, described as free to use, adapt and share, which for a set of presentation rules is exactly the right licence.

Editorial conclusion

This is worth reading even if you never install it, because the rules are a specific and defensible position on what an academic deck should be, and the ghost deck test in particular is something you can apply to a deck you already have. Two things to know if you do install it. The skill is an overlay rather than a generator: it does not produce the file, it delegates that to a separate built-in skill, so it inherits whatever that one does and breaks if the pair is separated. And the whole set of standards only applies once the assistant decides the request is academic, which is an automatic decision you do not control. The MIT licence lets you adapt and share the rules, so the practical use is as much reading material as tooling.

Frequently asked questions

Official sources

1. Gabberflast/academic-pptx-skill on GitHub
2. Issues
3. License: MIT
4. README