Open-source project
crazyykhllc-bit/CyberPPT avatar
crazyykhllc-bit/CyberPPT

CyberPPT: a Codex Skill for consulting-style PowerPoint decks

一个用于生成高密度、可编辑、咨询风格 PowerPoint 的 Codex Skill,支持 SCR 叙事、风格确认和 PPTX 质量检查。

1,718 stars173 forksPythonMIT

At a glance

What is it?
CyberPPT turns source documents into a high-density, editable PPTX through a three-stage pipeline of evidence tables, SCR storylines and page blueprints. It is built for consulting decks, not for talks, and its own README sets the ceiling at roughly 90% blueprint fidelity.
Who is it for?
Adopt CyberPPT if you produce dense, evidence-backed decks such as industry research, brand strategy or board material, and you are willing to work through all three stages with Codex. Do not adopt it for talks, personal narrative or any format where sparse slides are the point, and do not expect a one-shot run: the README states the first page or two usually take longest and go wrong most often.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 60 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

What CyberPPT solves, and who it is actually for

CyberPPT is a Codex Skill that converts documents, research material and business data into high-density, editable, consulting-style PowerPoint presentations. The README lists the intended ground clearly: industry research, consumer goods analysis, brand strategy, e-commerce analysis, user research, executive reporting, board material, client proposals and project retrospectives.

The exclusion is just as explicit. The README names low-density, text-light decks as out of scope: presentations, personal style expression, narrative, sharing and opinion-driven slide decks. That is an unusual thing for a project to put in its own README, and it is the right call. A tool that enforces an evidence table and a density gate on every page will fight anyone whose deck is meant to be five words and a photo.

The design premise is stated directly: the core is not template filling. Source material is first converted into an auditable evidence chain, then passed through SCR argumentation, page density planning, a visual blueprint and strict gates before a PPTX is produced. The audience is therefore someone who already has source documents and needs a defensible deck, not someone starting from a blank canvas and an idea.

The four-stage pipeline: evidence table, SCR, blueprint, restore

The mandated flow has three user-facing stages, with a delivery step at the end.

Analysis builds an MBB evidence table that records conflicts, gaps and caveats, then brainstorms two or three storylines and converges them into an SCR structure, a page-by-page outline, a chart plan, an information density target and a component list. Blueprint presents eight fixed visual styles; once the user picks one, the style number, palette, grid, heading hierarchy, chart language and page density are locked, and an ImageGen blueprint is generated for every page. Restore rebuilds the PPTX from that blueprint, separating a complex visual asset layer from an editable information layer, using native text, shapes, tables, charts, SVG paths or custom geometry. Delivery hands over the PPTX, full-page renders, slide_manifest.json, visual_qa_gate.json and the strict QA result.

The README is blunt that the three stages cannot be skipped, and that is what it claims gets you to roughly 90% blueprint fidelity. It also warns that AI attention drifts during restore: if the model starts rebuilding everything in one pass, the README says to stop it and instruct it to restore page by page, otherwise it produces a skeleton only. The first one or two pages are described as the slowest and most error-prone, which the README attributes to first-run friction rather than a defect.

Installing CyberPPT into your Codex skills directory

The README gives one install path: clone the repository with Git into the Codex skills directory, keeping the folder name cyber-ppt. The folder root must contain SKILL.md.

powershell
git clone https://github.com/crazyykhllc-bit/CyberPPT.git "$env:USERPROFILE\.codex\skills\cyber-ppt"

After cloning, the README's usage section says to point Codex at the skill explicitly, naming the folder and the source document, for example telling it to use the CyberPPT skill under a given folder to build a deck from an uploaded document. The analysis stage then reports how many pages it plans to produce; you can override that count if you want a specific length.

Updating is a pull inside the same directory.

powershell
cd "$env:USERPROFILE\.codex\skills\cyber-ppt"
git pull

Validation runs against a finished deck, a manifest and a visual QA file, with --strict gating the manifest and visual QA checks.

bash
python scripts/validate_pptx.py path/to/deck.pptx --manifest path/to/slide_manifest.json --visual-qa path/to/visual_qa_gate.json --strict --json-out path/to/report.json

The README states that errors under --strict require rework. Note what the README does not document: there is no rollback procedure, no uninstall step, and no version pinning for the clone.

The gate system is the real product, and it is demanding

CyberPPT ships fifteen named gates. Reference Gate blocks a stage until the corresponding reference file has been read. Evidence Gate requires every fact, number, judgement and recommendation to trace back to source material. Storyline Gate refuses a single outline in place of two or three brainstormed and compared storylines. Density Gate requires each page to carry density, a component list, a chart plan and a SO WHAT. Style Gate requires eight independent 16:9 samples rather than a written style description. Blueprint Gate blocks PPTX generation until page blueprints are confirmed. Asset Admission Gate requires each image asset to justify its source, necessity and effect on editability. Editable Layer Gate fails a deck whose main information has been flattened into images. Visual Semantics Gate, Curve Trace Gate and Spatial Registration Gate police fidelity of chart semantics, curved lines and anchor alignment. Container Overflow Gate, Typography Gate and Render QA Gate cover text overflow, a fixed C0/T1-T14 type scale, and page-by-page rendering against the blueprint. Strict QA Gate runs validate_pptx.py --strict.

The stated principle is that structural editability and visual fidelity are equally hard thresholds, that passing strict QA does not mean the deck looks right, and that the ImageGen blueprint is a reference rather than the final slide background. That third point matters: it means the tool is not simply placing generated images behind text. It rebuilds content natively and uses imagery only where the Asset Admission Gate allows it.

Where CyberPPT breaks down

The README concedes the failure modes rather than hiding them. Curve charts are named as the hardest thing to restore. Small icons are frequently wrong, and the README's remedy is to point out the problem and ask for a replacement. Line breaks and font sizes are left for manual editing.

Fidelity is probabilistic. The README describes reaching 100% as possible but random, comparing it to a gacha draw: sometimes it lands in one pass, sometimes it drifts. Pushing for full fidelity costs debugging time and tokens, and the README's own recommendation is to let AI handle 90% and fix the last 10% yourself, or simply use the blueprint as the deliverable.

The workflow is also interactive by design. Three stages, a style selection, a blueprint confirmation and page-by-page restoration mean this is not a batch converter you fire at a folder. If your deck is meant to be sparse, or if you want a single automated pass, CyberPPT is the wrong tool, and the README says so about the sparse case itself. There are no published releases in the repository, so there is no versioned artifact to pin; updates arrive through git pull on the default branch.

How it differs from template-driven and python-pptx pipelines

The nearest alternative most engineers reach for is python-pptx, building slides from a fixed layout with code. The difference is where the intelligence sits. A python-pptx pipeline encodes layout decisions in advance and applies them to data; CyberPPT derives the layout from the source material each time, through an evidence table, a storyline convergence and a per-page blueprint, then rebuilds the result with native shapes, tables and SVG paths. python-pptx gives you deterministic output and no gate system; CyberPPT gives you a density and evidence discipline that a layout script has no concept of.

The second comparison is a template-based deck builder, where a corporate template supplies the visual language and you fill placeholders. CyberPPT's Style Gate rejects a written style description in favour of eight independent 16:9 samples, and its Blueprint Gate locks palette, grid, heading hierarchy and chart language before any PPTX exists. The trade is speed and predictability for fidelity to the argument. If your template already encodes your firm's standards and your content is settled, a template route is faster. CyberPPT is aimed at the case where the argument itself is still being formed from documents.

Licence, maintenance and what an upgrade costs you

CyberPPT is MIT licensed, with the README pointing to the LICENSE file. MIT permits commercial use and modification, but it also means you carry the deck quality yourself: there is no warranty attached to the output, and the README's own 90% figure is a statement of intent rather than a guarantee. If you redistribute the skill or a derivative, the licence text travels with it. That is a summary of the licence, not legal advice.

Maintenance signals are limited. The repository is not archived, and the last push was on 2026-07-20. There are no releases, so there is nothing to pin and no changelog to read. Upgrading means git pull inside the cyber-ppt folder, which will overwrite local edits to tracked files. If you tune the skill for your own house style, keep those changes outside the cloned directory or in a branch, because the documented update path has no merge step.

The skill depends on reference files under references/ and scripts/validate_pptx.py for gating, so a pull can change both behaviour and the validation contract in the same move. Re-run the strict validation on a known deck after any pull before you trust it on client work.

Editorial conclusion

Adopt CyberPPT if you produce dense, evidence-backed decks such as industry research, brand strategy or board material, and you are willing to work through all three stages with Codex. Do not adopt it for talks, personal narrative or any format where sparse slides are the point, and do not expect a one-shot run: the README states the first page or two usually take longest and go wrong most often. Before you commit to a deck, verify that SKILL.md sits at the root of a folder named cyber-ppt, that you can run scripts/validate_pptx.py with --strict against a sample deck, and that you accept the README's own 90% target rather than chasing 100% fidelity.

Frequently asked questions

How do I install CyberPPT as a Codex Skill?

Clone the repository with Git into your Codex skills directory and keep the folder name cyber-ppt; the folder root must contain SKILL.md. The README gives the Windows path under $env:USERPROFILE\.codex\skills\cyber-ppt.

What kinds of presentations is CyberPPT not suitable for?

The README excludes low-density, text-light decks: presentations, personal style expression, narrative, sharing and opinion-driven slides. It is aimed at dense consulting-style material such as industry research, brand strategy and board reporting.

How do I check that a CyberPPT deck passes its quality gates?

Run scripts/validate_pptx.py against the deck with --manifest, --visual-qa and --strict, optionally writing a JSON report with --json-out. The README states that errors under --strict require rework.

Official sources

  1. crazyykhllc-bit/CyberPPT on GitHub
  2. Issues
  3. License: MIT
  4. README
Community notes

Community notes