AI272/speaker: an evidence-grounded Codex skill for academic presentation notes

What AI272/speaker is for, and who should reach for it

The problem this project targets is specific: speaker notes written from text extraction alone miss what is actually on the slide. Charts, screenshots, SmartArt, axis labels, legends, tables and text baked into images do not appear in a plain text-box dump, so a generated script can sound fluent while referring to content the presenter cannot see. The README states the skill is designed to keep speaker notes grounded in the actual slides, and lists the failure mode it is reacting to: tools that only read text boxes.

The audience is narrow. You need a real .pptx file, a Codex or Claude Code client to run the skill in, and a talk long enough that pacing matters. The example prompt in the README asks for a 15-minute academic presentation script with the clean script injected into speaker notes and a full rehearsal document generated alongside. If you are writing a five-slide internal update, the machinery here is heavier than the task.

The evidence chain: XML, rendering, OCR and vision review

The workflow runs in one direction. An input .pptx goes through structured extraction, then slides are rendered to PNG, then OCR and a visual inventory are built, then vision review runs, and only after that does the skill produce a Deck Comprehension Brief, a narrative arc, slide-by-slide display notes, and finally clean notes that get injected back into the PPTX.

The evidence chain diagram in the README shows what feeds the inventory: PPTX XML, text boxes, tables, native charts, rendered slide images, OCR text and vision review all converge on a single visible-element inventory, which is what the notes are written against. Extraction is layered rather than single-pass. Native chart reading attempts titles, categories, series, values, axes and legends, and an OOXML fallback pulls additional slide XML text that python-pptx does not expose, including some SmartArt or grouped-shape text. The README is honest about the limits of that word: it says the chart reader attempts these fields, not that it always succeeds.

Version 0.8 tightened two parts of this chain. Compact extraction drops redundant raw OOXML dumps and non-visual geometry while keeping picture bounding boxes, so the intermediate JSON is smaller. Region-scoped OCR runs only on picture and media regions, on the reasoning that text boxes, tables and charts already come from XML, with an automatic full-slide fallback when that assumption fails.

Installing the skill and running a first deck

The README points at a packaged skill file rather than a package manager. The current package is speaker-v8.skill, and the internal skill name is ppt-speech-writer. Installation goes through your Codex client's skill import flow. After that, you invoke it when you need speaker notes, presenter notes, a speech script or narration for a real .pptx file.

For Claude Code, the repository ships a project skill under .claude/skills/ppt-speech-writer, which the layout shows as a symlink to ../../ppt-speech-writer. Open Claude Code from the repository root and call it by name. If Claude Code is already running, reload skills after pulling updates.

/ppt-speech-writer

The README gives this example prompt for a first real run. Note that it states the duration and the deliverable explicitly, because the skill budgets words against the requested length.

Use speaker / ppt-speech-writer to write a 15-minute academic presentation script
for this PowerPoint deck. Inject the clean script into speaker notes and also
generate a complete display-version rehearsal document.

Expect a summary plus file paths in chat rather than the whole script pasted back. The README says the default delivery is concise, and that replying `show notes` prints the complete notes. The top-level outputs you should look for are `<deck-stem>-with-notes.pptx`, `<deck-stem>-display.docx`, a `<deck-stem>-display.md` fallback, and `<deck-stem>-vision-review.md`. Intermediate evidence files stay under `work/`.

One behaviour is worth knowing before you start: the README states the skill must explicitly confirm the output language before writing notes, and that it does not infer the note language from the language you use in chat. If you skip that confirmation, you are relying on a step the documentation says is mandatory.

The pause-aware pacing model and where it still misleads

The 0.8 release notes describe a deterministic pacing model: roughly 110 words per minute for English and 165 characters per minute for Chinese, with time reserved for slide transitions and `[PAUSE]` marks. The stated reason is a concrete failure. A script labelled as 15 minutes previously ran to about 1,800 words and overran to roughly 30 minutes. Under the new model a 15-minute talk targets about 1,300 to 1,400 words, and SKILL.md computes a per-slide budget so no single slide eats the whole slot. The timing table reports words or characters, budget and pauses with a TOTAL row.

The trade-off is that a deterministic wpm figure is a planning device, not a measurement of you. A presenter who speaks slowly, or who stops to answer questions, will still overrun a script built to 110 wpm. The model also reserves time for `[PAUSE]` marks, which means the pause markers are load-bearing: strip them out and the arithmetic no longer describes the talk you will give. Treat the word budget as a ceiling to rehearse against, not a guarantee.

Where AI272/speaker is the wrong tool

The skill is built around a real .pptx and a notes pane. If your deck lives in Google Slides, Keynote or an online editor, the injection step has no target, and the README documents no export path for those formats. Vision review is also described as producing a packet for a vision-capable agent or human reviewer, which means the review is a handoff, not an automatic verdict. If nobody reads `<deck-stem>-vision-review.md`, visually complex slides are inventoried but not actually checked.

The .docx rehearsal document depends on python-docx. When that library is unavailable the README says the fallback is Markdown, so a pipeline that expects a Word file downstream will break on a machine without it. Extraction quality is another boundary: the chart reader attempts to read axes, legends and series values, and the OOXML fallback covers some SmartArt and grouped-shape text. A deck that relies on unusual chart types or heavy animation may produce a thinner inventory than the slide deserves, and the skill does not promise otherwise. Finally, the repository does not state a licence, which is a real question for anyone embedding this in a commercial workflow.

How it differs from python-pptx scripting and Pandoc-based note generation

The closest alternative for most engineers is writing a short python-pptx script that walks shapes, pulls text frames and tables, and dumps them to a document. That approach is transparent, dependency-light and easy to debug, and it shares one property with this skill: both read the file rather than the rendered slide. The difference is what happens next. A python-pptx script has no rendering step, no OCR pass over picture regions, and no vision review packet, so a chart whose meaning lives in its visual encoding contributes little beyond whatever text the XML carries.

A second alternative is a document-conversion route, extracting the deck to text or HTML with a general converter and writing notes from that. It scales to many decks at once and needs no agent client. It also flattens the slide into prose, which is precisely the thing the README argues against for visually dense academic material. The choice is between a pipeline that is cheap to run on a hundred decks and one that spends rendering, OCR and review effort on a single deck. AI272/speaker only makes sense when the single deck matters.

Maintenance, upgrade cost and licence status

The last push to the repository was on 2026-06-23, and the most recent release, v0.8.0, was tagged the same day. Two earlier releases, v0.6.0 and v0.7.0, landed on 2026-06-03. That is a burst of activity rather than a long cadence, and the repository is not archived.

Upgrading between 0.x releases is not free, judging by the 0.8 notes. The compact extraction mode, the region-scoped OCR scope and the compact vision-review format all change intermediate artifacts, and the glossary toggle changes the shape of the display document. Anything that consumes the JSON under `work/` should be re-checked after an upgrade rather than assumed compatible. The skill package itself is versioned by filename, speaker-v8.skill, so the installed artifact and the repository version can drift apart if you import once and never revisit.

The licence is not stated in the repository, so the terms under which you may redistribute or modify this skill are unknown. That is a question to resolve with the repository owner before the skill becomes part of a shipped product, not something to infer from the README.

Editorial conclusion

Adopt AI272/speaker if you already run Codex or Claude Code and need grounded notes for a real, visually dense academic deck, and you can accept that the skill must be told the output language before it writes. Do not adopt it as a general text-to-speech or subtitle pipeline: the workflow is built around a single .pptx and a notes pane, and the repository does not document the licence. Verify first that your client can import speaker-v8.skill, that python-docx is present if you want the .docx rehearsal document rather than the Markdown fallback, and that your deck's charts and SmartArt survive the extraction pass.

Frequently asked questions

Official sources

1. AI272/speaker on GitHub
2. Issues
3. README
4. Releases