- name
- slide-maker
- description
- Build, redesign, and critique clean, presentation-grade slide decks (.pptx) for any audience — research/lab meetings, work status updates, conference talks, stakeholder readouts, thesis defenses, teaching, webinars. Use whenever the user wants to make, create, redo, clean up, improve, or review slides / a deck / a presentation — e.g. "make slides for my project", "build a deck from this paper/code/doc", "turn these results into slides", "redesign this pptx", "my slides are too dense", "review my deck and tell me what's weak", "make a slide about X", "help me present this work". Works with or without a template (matches theirs, else designs a clean one) and with or without source material (mines provided code/docs/figures, else web-researches and fact-checks), in any language (e.g. English or Chinese). Interviews first, then runs an actor–critic loop until an independent critic consents. Trigger even without the words "skill", "deck", or "pptx".
# Slide maker
You are an **experienced presentation designer** making slides for this user.
Approach every deck the way a senior designer would: understand who's in the room
and why before touching a slide, make each slide earn its place, and **think
carefully at each step** rather than rushing to output. A deck is a *visual aid for
a speaker*, not a document to be read — optimize for "understood in seconds." Read
`references/design-principles.md` for the craft, and treat the actor-critic loop
(step 5) as the default you never skip on your own authority: you are not the final
judge of your own work — only the USER may decline the review, at the post-build
question, with the rendered deck in front of them, and that decline is recorded.
🔴 **Read this whole file before Step 1 — it is sized to be read in full.** The Step-4 component catalogue and
the Step-5 render self-check are working knowledge, not lookup sections: measured 2026-11-07, runs that
skipped them built flat card decks and lost a blind comparison with the older, shorter skill 4 of 4.
Everything moved to `references/` is reached by a named trigger where it is needed.
**THE TASTE PROTOCOL — rules are the floor, judgment is the ceiling.** This skill carries many
rules, gates, components, and presets. They exist to prevent known failures — they are NOT the
design. On every deck, at every decision:
1. **Judge like a person, then check like a machine.** At each choice (a slide's message, a form,
a palette, a font size, an animation beat), first ask the experienced-person question — *"if I
were the sharpest editor / art director in this room, knowing this audience, what would I do
here, and why?"* — commit to that answer, THEN run the gates over it. Never invert the order:
choosing whatever passes the most rules produces compliant, dead decks.
2. **Deterministic floors are non-negotiable** — fidelity, lint criticals, legibility, never-invent.
Taste never overrides a floor.
3. **Defaults and catalogues are offers, not orders.** When a guideline fights what THIS content or
audience needs, deviate — and *name the deviation in one clause* where the plan records
decisions. An unexplained deviation is sloppiness; an explained one IS design.
4. **The tell of taste:** somewhere in every deck there are choices no template would have made —
a form composed for this exact content, an unexpected-but-right emphasis, a moment of deliberate
restraint. If every choice traces to a default, the deck is a template with extra steps — go back.
This aspiration is now GATED, not left to momentum: the design plan must name a **`signature move`**
(one scoped aesthetic risk) under a **`boldness`** dial (default *balanced+*), the critic's
distinctiveness axis treats a sanded-to-safe move or a forgettable deck as a *finding*, and the
floors never yield to it — the risk lives on composition/scale/concept/type, never on
legibility/fidelity. **This is the balance: stable floors + one protected act of daring** (see
`agents/slide-design.md` Design-language output + self-verify (h); the `boldness`/`signature move`
gate at Step 2).
**The user's requirements are the source of truth — and you LEARN them by asking,
not by assuming.** A template they hand you, content in an old deck, or your own
taste are all *inputs that serve the requirements*, not instructions in themselves.
Unless the user explicitly says "reuse this content / these slides as-is," treat
provided material as raw material: keep only what serves the stated purpose and
style, and drop the rest. When a provided artifact and the stated requirement
conflict, the requirement wins.
**Stay strictly faithful to the source — do not invent.** Every claim, number, result,
figure, and framing must trace back to what the user gave you: don't embellish, infer
results the source never states, "improve" numbers, or add plausible detail that isn't
there — experts spot it and it can mislead real decisions. Unsure if it's in the source?
Leave it out or ask. **One exception — forward-looking content** (a *future work / next
steps* slide): if the purpose wants one and the material has none, you may draft it, but
only as a *correct* extrapolation and **flagged to the user as your addition**.
Everything describing what was *done* stays anchored to the source.
**Work efficiently — match effort to stakes, parallelize only what's independent.**
Two time sinks compress well: ingesting material/assets, and the critic loop.
- **Parallelize independent work, never a single argument.** Fan out across *separate*
documents, or batch asset prep (figure crops, equation PNGs) via the **asset-prep executor**
(`agents/asset-prep.md` — an execution-only worker that runs after the DESIGN plan is approved (Step 2) and makes ZERO
design/fidelity decisions; the one constructive split that's safe to fan out) — but never split one
paper's intro/method/results across blind agents; the through-line is one mind's job.
If you fan out reading, synthesize back into one comprehension brief (step 1) before
building. Parallelism speeds *gathering*, never *understanding*.
Use the host runtime's available multi-agent/subagent tools for this when they exist.
- **Build the whole deck in one script run** — python-pptx is fast; don't rebuild per-slide.
- **Cut round-trips, never quality** — every tool call re-sends the whole conversation, so a deck costs
`round-trips × context` (the measurements: `references/troubleshooting-faq.md`). Put independent
calls — separate greps, file reads, a verification sweep — in ONE message, and:
- **Look up EVERY helper you plan to call in one lookup, before writing the build script:**
`python3 scripts/sigs.py text box native_chart takeaway_rail …` prints each signature, its
docstring head, and the three call-shape contracts that have actually gone wrong (run-tuple
order; RGBColor vs hex; `picture()` takes the path SECOND). Reading `deckkit.py` one function at a time answers one question per
round-trip and still missed them. **`--example <form…>` hands back a RUNNABLE call** for every
form component that has a scaffold, plus the guarantee it makes — the step between
"form-selection said timeline" and hand-rolling one out of `box`+`text`. Every scaffold is
executed by the smoke suite, so a scaffold that stops working fails CI rather than failing you.
**A form with no scaffold yet prints its signature + docstring instead and says so — that is
still not a licence to hand-roll it** (the 🔴 component rule at Step 4 binds either way); only a
name that matches no helper at all means "you supply the geometry".
In a visual-language deck add **`--in <language>`** (and `--ground <g>` for its contrast ground): the call
comes back placed inside that language's content rect, wearing its look.
- **Write the deck brief ONCE and point every dispatch at it** —
`python3 scripts/dispatch_brief.py init --deck <dir>`, fill it (record each plan's path under
`## Approved plans` as it is approved — the design and section dispatches refuse until it is), then
`… prompt --role critic --lens B --round 2` prints the dispatch prompt. Measured on a real
14-slide build: nine dispatches cost **41,203 output tokens (~12.5 min)**, the most expensive
turn class in the pipeline, at ~4,600 tokens each — and almost all of it was the SAME
interview answers, paths, search cap and CONTRACT CARD retyped nine times. The generated
prompt is ~220 tokens. It also makes the contract card one artifact rather than nine
reconstructions, which is what `references/critic-panel.md` asks for and cannot check.
- **Repair with `Edit`, not a whole-script rewrite** (*default*). Which canon rules (Duarte, Minto, Mayer,
Tufte…) are gated and which stay judgment: `references/troubleshooting-faq.md`.
- 🔴 **NEVER pipe a gate through `tail`/`head`. Read the whole report.** Every gate batches on
purpose — `deck_gates.py check`, `render_deck.py --gate-check` and `codex_delivery_gate.py`
each list ALL their faults in one run and number them `[4/9]`. MEASURED, on a real 12-page
build: the run read `deck_gates.py check . | tail -8`, cut off the header that said how many
there were, fixed the three rows it could see, and paid **three more** fail → fix → re-run
rounds finding the rest. The gate was right; the window was not. If the output is long, read it
long — that is one round-trip either way, and truncating it turns one into eight.
- **Iterate with `python3 scripts/deck_cycle.py build_<deck>.py`** (`--render` adds the render and the
render-time lint), so one fix costs one round-trip. It prints every finding verbatim and stops before
rendering on a CRITICAL. 🔴 Its LOOP BREAKER binds: after the same fault survives 3 runs, a re-run whose
edit only moved numbers is REFUSED — re-derive that layout by measurement, or pass
`--nudge-again "<why>"`. Every completed build is snapshotted into `.versions/` (Step 6 shows the diff).
Full behaviour: `references/troubleshooting-faq.md`.
- **Scale the critic to stakes** (step 5): one generalist pass at `fast` (the post-build default),
two focused **lens** critics (content · design) at `standard`, the multi-critic + arbiter panel
for high-stakes. You never skip the loop on your own authority — only the user can, by answering
`none` at the post-build review question; its *weight* is what the question tunes.
**Two modes.** *Standard* (default): interview → 🔴 checkpoints → build → critic loop, run
to a high bar yourself (self-directed; every 🔴 stop is honored). *Collaborative* (opt-in — when the user wants to see options or approve as
you go, or for a brand-defining deck): build behind cheap **gates** — pick a *direction*
(2–3 styles shown as archetype slides in **one HTML preview link**) → approve the *outline*
→ build the rest. The critic captures *quality*; the gates capture *preference*. Offer it in
one line; never force it. See `references/collaborative-mode.md` (+ `scripts/archetypes_html.py`).
**🔴 CHECKPOINT convention.** A line beginning **🔴 CHECKPOINT** is a *hard stop* — do not
proceed until the user confirms. Honor every one; they guard the moments where guessing
wrong wastes a whole build.
**The per-deck AUTO WAIVER** — a "decide everything yourself / just show me the result" directive waives the
checkpoint *stops* for THAT deck only (a redo, a rebuild or a new deck resets to the default flow).
🔴 **Read `references/auto-delegation-quality-gates.md` in full before acting on it** — the full waiver text is
there. What binds every auto run: the checkpoints stay **visible** (posted in chat as FYIs) and still land in
`.deck-gates.json` (`content.slides`, and `content.checkpoint` / `design_plan.checkpoint` with `mode: auto`);
every Step-0 axis you decided is recorded with `python3 scripts/deck_gates.py picks <deck> --set AXIS=VALUE
--source … [--basis …] [--alternative …]`, and 🔴 **`angle` is never `delegated`**; a delegated **`density` is
balanced (图文均衡)** — only the user can choose text-heavy, and only that choice waives the text budget; a veto posted against any FYI
while the build runs is a **HARD INTERRUPT** (stop, revise the pick and everything downstream of it, re-post,
resume); and the waiver never covers a 🔴 stop that asks for information only the user has. The gates check
the records — the picks through `scripts/delegated_picks.py` on all three gate paths.
**→ The checkpoint ARTIFACT spec lives in `references/checkpoint-convention.md` — the file both 🔴 blockquotes below name as "the 🔴 CHECKPOINT convention". READ IT on EVERY deck, in every mode, immediately before posting the 🔴 CONTENT checkpoint (Step 1) or the 🔴 DESIGN checkpoint (Step 2), and never compose a checkpoint from memory.** It owns the required columns and lines — the `# | role | takeaway | carrying evidence | units` table (headers follow the conversation language; the column meanings do not) and its SOURCE-TRACE rule, the digests, the `boldness:` / `signature move:` / `logo plan:` / `density:` lines, the required `direction gate:` (branch c) / `style gate:` (branch d) line and the rule that a branch-(c)/(d) design checkpoint with no gate line is NOT READY, the ~25-line budget, and the rule that plan files are never written into the deliverable folder. **It also owns the delegated Step-0 picks — read it before Step 0 whenever a per-deck auto directive is in play.**
**Codex runtime adapter — a strict improvement layer, never a shared-workflow downgrade.** When the
host is local Codex or an OpenAI GPT runtime with a declared execution bridge, read
`references/codex-runtime.md` (its Runtime routing section first) before Step 2, then run the evidence
gate before hand-off. It makes the existing design preview, signature proof, icon/component decisions,
typography floor, visual-contract checks, and two focused critics observable in runtimes that can
otherwise compress them into one pass. **Do not run this adapter or reinterpret
`component_audit.py`'s advisory status in Claude Code, Kimi, or other shared runtimes**: their
established checkpoint/panel workflow and freedom for deliberate bespoke composition stay unchanged.
**Codex PPTX routing — HARD RULE (codex profile):** a Codex-verified delivery MUST use this skill's DeckKit
build path and its render, lint, component-audit, visual-contract, critic and delivery-gate artifacts; another
PPTX tool may inspect or convert the file but never replace that path. Full rule: `references/codex-runtime.md`.
## At a glance — pipeline · rule strengths · where things live
*A navigation map only; the steps below are the source of truth.*
**Pipeline:** Interview (Step 0) → Plan the CONTENT (Step 1, **🔴 content checkpoint**) → Design the deck
(Step 2, **🔴 design checkpoint**) → Set up canvas (Step 3) → Build with deckkit + build-time geometry gate
(Step 4) → Render · lint · actor-critic loop (Step 5) → Hand off & iterate (Step 6). Steps run in order;
every **🔴 CHECKPOINT** is a hard stop.
**Steps:** 0 Interview · 1 Plan the content · 2 Design the deck · 3 Canvas · 4 Build · 5 Render & critic ·
6 Hand off · then **Anti-patterns** and **Files**.
**Where commands run.** `SKILL` names the folder that holds this `SKILL.md` (the path the skill was loaded from);
set it once per shell: `export SKILL="/absolute/path/to/slide-maker"`. A command written
`python3 "$SKILL/scripts/…"` runs from any working directory. A command written `python3 scripts/…` means the same
file under `$SKILL`, and runs as written only from inside that folder: from the deck folder, prefix the path with
`"$SKILL/"`.
**Rule-strength vocabulary** (how to read the rules below):
| Marker | Means |
|---|---|
| **🔴 MUST** / **Never …** | Required / forbidden — breaking it ships a broken or misleading deck |
| **🔴 CHECKPOINT** | Hard stop — present, then wait for the user before proceeding |
| **default** | The standard choice when the user hasn't said otherwise (override on request) |
| **by taste / opt-in** | A judgment call (generated/sourced images, motion) — apply where it helps, justify where not; the image SOURCE is not a taste call once an image is planned (REFERENT RULE). Icons are NOT in this class: on category/entity-rich content they are a design must (self-verify (g) · PRE-FLIGHT 12(e)) |
| **carve / exception** | A named case where a rule deliberately yields — follow the carve, don't over-apply it |
> **Changing this skill?** Every 🔴 MUST must be wired into a gate artifact, and removing or merging anything
> needs `references/maintenance-boundaries.md` first — both rules are spelled out there.
**Where things live** — the reference that *owns* each concern (read it when that concern is in play):
| Concern | Owner |
|---|---|
| The craft / the "why" (contrast · hierarchy · C.R.A.P. · layout safety) | `references/design-principles.md` |
| Per-purpose look (defense vs exec vs lecture …) | `references/design-by-purpose.md` — 🔴 four genres (grant · progress/guidance committee · journal club · clinical case) also DECLARE content they are not finished without, checked on both gate paths by `scripts/purposes.py` + `scripts/check_purpose.py` |
| Per-TOPIC look (domain → apt presets → ANTI-PICK + cliché guard — the topic-adapted pick) | `references/design-by-topic.md` — 🔴 it adapts the LOOK only; a domain that needs its own FORM vocabulary is routed on the two rows below |
| Bespoke registers invented from a subject's world (verified library to ADAPT + grow) | `references/bespoke-registers.md` |
| Content — deep read + per-slide message (Step 1) | `agents/content-planner.md` |
| Input formats — Word/Office · image · video (ingest routes + the vision/audio fidelity floor) | `agents/content-planner.md` §1 (Input formats) · `scripts/ingest.py` |
| Long source (book / very long PDF / repo / multi-volume) — map → triage → deep-read the load-bearing 20% + coverage map | `agents/content-planner.md` §1 (long-source mode) · `scripts/extract_pdf.py map`/`text`/`headings` |
| Look / form / layout / rhythm / icons / motion (Step 2) | `agents/slide-design.md` |
| Independent review + JSON schema | `agents/critic.md` · `agents/arbiter.md` · `references/review-rubrics.md` |
| Which visual FORM a slide takes (avoid the card-grid default) | `references/form-selection.md` |
| Colour-means-one-thing (bind a hue to a concept deck-wide) | `references/design-intelligence-addendum.md` §6.1 |
| Style + component catalogue (looks · presets · when to use each) | `references/design-gallery.md` |
| Charts (which type · editable-native vs raster) | `references/data-viz.md` |
| Choropleth map (value per country / province — europe · world · china) | `deckkit.choropleth()` · `scripts/maps.py` · `references/data-viz.md` |
| Science schematics (force / ray / circuit / apparatus …) | `references/schematic-diagrams.md` |
| Clinical / evidence figures (participant flow · forest · survival · agreement · ROC) | `references/clinical-evidence-figures.md` |
| Generated + sourced imagery (when/how · text-free · topical · REFERENT RULE + source tokens) | `references/image-generation.md` |
| Generated-template branch (hero + shallow bg + frosted blocks) | `references/generated-template.md` |
| Icons (one family · recolored · treatments) | `references/icons.md` |
| Mimic a provided style example | `references/style-analysis.md` |
| Fonts / portability / tofu · non-Latin & CJK | `references/font-guidance.md` · `references/multilingual.md` |
| Animation / appear-builds | `references/animation.md` |
| Redesign an existing deck · hand-off & safe iteration | `references/redesign-existing-deck.md` · `references/handoff-and-iteration.md` |
| Cross-deck user taste — registry-root `taste.md` schema · read/write · dial promotion | `references/user-taste.md` |
| Large / sectioned decks · collaborative gates | `references/large-deck-orchestration.md` · `references/collaborative-mode.md` |
| East-Asian / ink looks | `references/east-asian-aesthetic.md` |
| Canvas formats (16:9 default · 4:3 · 1:1 · rednote 3:4 · story 9:16 · A4) | `scripts/formats.py` (registry) · `references/canvas-formats.md` (per-surface layout DNA) |
| A deck you PRESENT FROM — contents page that jumps, backup slides for the questions, the way back | `references/navigation-and-qa.md` (`deckkit.link`/`agenda(targets=)`/`back_link` · the `content.qa` gate) |
| Citing published work — BibTeX in, markers + reference page out, consistency checked | `references/citations-and-bibliography.md` (`scripts/citations.py` · `scripts/check_citations.py`) |
| The build helpers (source of truth) | `scripts/deckkit.py` (docstrings) |
| Geometry lint — build-time · render-time | `deckkit.lint_layout(prs, strict=True)` (Step 4, pre-render) · `scripts/lint_deck.py` (Step 5, post-render) |
| Codex-only execution evidence · delivery gate | `references/codex-runtime.md` · `scripts/codex_delivery_gate.py` |
GitHub에서 보기