/slide-maker

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; t