Skip to main content

slide-maker

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".

ソース情報

リポジトリ
addsumtech/slides_maker
ソースの最終更新活動
2026年11月8日 15:28
検出された SKILL.md の言語
英語
スター
663
フォーク
61

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

ファイルエクスプローラー
100 ファイル

SKILL.md を表示中

SKILL.md
ソースの指示 · 読み取り専用プレビュー
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で見る
この SKILL.md は非常に大きいため、SkillsMP では最初のセクションだけを表示しています。 GitHubで見る