/slideware

name: slideware
description: "Create style-driven slide decks as PowerPoint (.pptx via pptxgenjs) or HTML (one self-contained index.html, edited in the browser and exportable to PowerPoint or PDF). Use when the user asks for a slide deck, presentation, pitch deck, training module, keynote, .pptx file, HTML or browser slides, or slides to share via link; wants slides from a brief or outline; references a style or brandbook, or a sample deck to mimic; or asks to update an existing deck. Trigger on 'deck', 'slides', 'presentation', 'pptx', 'pitch', 'keynote', 'reveal', 'HTML deck', or a .pptx or slide-deck .html as input or output. Styles resolve from the knowledgeware registry (five built-in styles plus brands in the user's knowledgeware home, managed by brandware), so decks match knowledgebase sites and chartware diagrams. If the format (PowerPoint or HTML) is not stated and cannot be inferred, ask before building."
license: MIT

slideware

> **Needs the knowledgeware plugin.** Styles and the style loader live in the plugin, two folders above this skill. If `../../scripts/load-style.js` doesn't exist, the skill was installed on its own (for example from a skills directory): tell the user it needs the whole plugin, `/plugin install knowledgeware --marketplace andisab/swe-marketplace`, and stop.

Generate brandbook-driven slide decks in one of **two output formats**:

| Format | Engine | Output | Guide | |---|---|---|---| | **pptx** | pptxgenjs + React icons + sharp (Node.js) | Real `.pptx` — opens in PowerPoint, Keynote, Google Slides | [pptx/FORMAT.md](pptx/FORMAT.md) | | **html** | the plugin's engine and runtime (Node.js 22, Chrome for checks and export) | One self-contained `index.html` — any browser, hostable, share-by-link, edited in place with E, exported to PowerPoint or PDF | [html/FORMAT.md](html/FORMAT.md) |

Opinionated about one thing in both formats: **don't make boring slides.** Plain bullets on white aren't worth your reader's time.

Step 0 — choose the format

Decide from explicit cues first:

• **pptx**: ".pptx", "PowerPoint", "Keynote", "Google Slides", a `.pptx` file as input/output, "they'll edit the slides afterward", corporate template workflows.
• **html**: "HTML", "web presentation", "browser", "host it", "share a link", "single file", "I'll edit it myself", embedding in a site, a slide-deck `.html` as input/output. An HTML deck also exports to PowerPoint, so "they need a .pptx too" doesn't rule it out.
• **Iterating on an existing deck** → keep its current format unless asked to convert.

**If neither the request nor context settles it, ASK the user** ("PowerPoint file or an HTML deck you can open in a browser/host?") before building — the two outputs are not interchangeable deliverables. Don't silently default.

Then read **exactly one** format guide (`pptx/FORMAT.md` or `html/FORMAT.md`) and follow it. Each guide has its own workflow, layout archetypes, pitfalls, and scripts under its directory.

Style / brandbook resolution (shared by both formats)

"Style" and "brandbook" mean the same thing — .md files describing a visual identity (palette + type + layout). Path convention: `$PLUGIN` = the knowledgeware plugin root, two directories above this skill (`../../`).

A style is a **name resolved through the registry**, never a path to a token cache: the brandware skill's resolution contract ([../brandware/SKILL.md](../brandware/SKILL.md) §Resolution contract) says where names are looked up (the user's `$KNOWLEDGEWARE_BRANDS_DIR`, then `$PLUGIN/styles/brands/`, then the five generic styles in `$PLUGIN/styles/`) and which markers decide when no name is given (`.knowledgeware` in the project, then `DEFAULT`). `node $PLUGIN/scripts/list-styles.js` lists what's installed. Slideware's own fallback, when nothing is named and no marker resolves: `style-1` (Editorial Light), and tell the user. Other inputs are staged first, then loaded by name or path: an explicit local `.md`/`.css` is read directly; a website is derived with `node $PLUGIN/scripts/derive-style.js <url> -o ./brand.md` (heuristic; verify against the live site); a Google Drive link is fetched with `python3 $PLUGIN/scripts/fetch-resource.py <url> <dest>`.

**Staging differs per format** (each guide shows the exact command):

• pptx consumes **tokens JSON** — `node $PLUGIN/scripts/load-style.js <name|path> -o style-tokens.json` (serves the `tokens.json` cache next to each `brand.md` when it's fresh, and rebuilds it otherwise).
• html copies the brand **into the deck** — `node $PLUGIN/skills/slideware/html/engine/cli.js new <dir> --brand <name|path>` writes the theme block (the brand's tokens, and its `css/slideware.css` refinements when it ships one), the CSS of the catalogue patterns the slides use, and the brand's logos; `refresh` updates them when the brand or the slides change ([html/FORMAT.md](html/FORMAT.md) §The brand).

**Fonts (handle silently)**: brandbooks name fonts; nothing embeds them. When building **pptx**, after resolving the style run `bash $PLUGIN/scripts/install-fonts.sh --check <name>` and, if Google Fonts are missing, install them with the same script without asking — just mention it in one line. Non–Google-Fonts families can't be auto-installed: fall back per the brandbook and tell the user which face to install manually. HTML decks load Google Fonts via `<link>`, so viewers (and you) need nothing installed.

**Missing tooling**: pptx previews need LibreOffice + poppler (`render-slides.sh` prints a NOTE and exits cleanly when they're absent — no PNGs means the check was skipped) and visual review needs browser MCP tools (find them via `tool_search`). When any of these are missing, still build and deliver the deck, say which check was skipped, and point the user to the plugin README's "Optional tooling" section for install commands.

Anti-monotony rule (shared)

The point is **content-shape variety**, not visual-archetype rigidity. A deck that walks one consistent story ca