SuperAPI AI Directory

paper-deck

Design & creation

View repository

Updated 10-14 09:20

About this skill

Paper Deck — Visual Slide Director

Turn papers/knowledge content intoslides that look like they were actually designed.

The core approach is not to rigidly arrange layouts with PPT objects, but to:

  1. First understand the content, and produce a deck brief and page-by-page narrative.
  2. For each page, clearly write down "what should the audience see, feel, and remember on this page".
  3. Use an image generation model to generate a 16:9 slide image.
  4. Composite into PPTX/PDF, and keep the prompts as source files that can be revised.

Image generation requirements that cannot be bypassed

Paper Deck's V1 is a raster-first AIGC slide image workflow. Unless the user explicitly requests "do not generate images", "draw with code", "only editable PPT", or "use HTML/SVG/Canvas generation", you must call a real raster image generation backend to generate images for each page.

It is strictly forbidden to pass off the following outputs as this skill's "generated image pages":

  • Full-page images drawn directly with Python/Pillow, SVG, HTML/CSS, Canvas, Mermaid, matplotlib, PPT shapes, or any local drawing code
  • Replacing image generation backend output with templates, pure layout scripts, screenshots, placeholder images, or manually combined elements
  • First drawing the full page locally, then applying only slight filters/post-processing and treating it as an AIGC slide image

Allowed local processing is limited to:

  • Moving, copying, and renaming image generation backend output files
  • Necessary format conversion, compression, size validation, and PPTX/PDF compositing
  • When the user explicitly chooses a hybrid approach, overlaying a small amount of editable text layers on the generated image background; in this case, it must be clearly recorded in deck-brief.md and the delivery notes as a "hybrid text layer", and you must not claim that all page text was completed by the image generation model

If the current environment has no available raster image generation backend, you must stop and explain that the image generation backend is missing; do not degrade to a local drawing alternative.

When to use

Suitable for:

  • Paper group meetings, defenses, reading groups, technical sharing
  • Visual presentations that need to "not look like a template PPT at a glance"
  • Users willing to accept that each page is a high-quality image, prioritizing overall look and communication impact
  • Needing page-by-page revisions: redo page N, change style, add realism, reduce AI feel

Not suitable for:

  • Needing multiple people to finely edit every text box in PowerPoint
  • Large numbers of tables, financial reports, and compliance materials
  • Needing to accurately replicate an existing corporate PPT master template

If the user needs a fully editable PPT, explain that this skill's V1 is raster-first; they can switch to regular PPTX tools, or generate a hybrid approach of "image background + editable text layer".

Workflow

Step 1: Input analysis

Accepts:

  • arXiv / DOI / web links
  • PDF paths
  • Markdown / text / articles
  • Existing outlines
  • Reference images or reference PPT screenshots

If it is a paper, prioritize reusing paper-analyzer reading approach: read the abstract, method, experiments, figures/tables, and conclusion; search the code repository when necessary. The goal is not to write a long document, but to extract a core narrative suitable for slides.

Output and save analysis.md:

  • Topic, audience, presentation scenario
  • The paper/content's one-sentence claim
  • 3-5 core points that must be explained clearly
  • Recommended page count, recommended style, language
  • Types of images to generate: cover, mechanism diagram, flowchart, data page, conclusion page, etc.
  • Real materials that can be used directly: paper Figures/Tables, PDF screenshots, user-provided screenshots, code screenshots, experimental curves

Step 2: Confirm before generation

By default, confirmation is required; do not generate images directly. Unless the user explicitly says "generate directly/no need to confirm/use defaults."

Keep questions to within 3:

  1. Page count and purpose: group meeting / defense / public sharing / business presentation, how many pages are needed?
  2. Style: see references/style-system.md。
  3. Whether to insert real materials: is it allowed to take screenshots from PDFs/paper figures, or will the user provide screenshots/images? If allowed, specify which real materials are expected to be used on which pages.

Recommended wording:

我建议做 12 页,风格用 journal-minimal:像 Nature/IEEE 论文图 + 正式学术汇报,清晰、克制、不花哨。
也可以换成 business-research 做商业研究分享,warm-notes 做手记风,或 liquid-glass 做 Apple 式玻璃质感。
这篇论文我建议在第 4 页插入原论文方法图局部截图,第 8 页插入实验曲线/表格截图,再基于这些真实素材做设计化排版。
确认后我会先生成 outline.md 和每页 prompt,再逐页出图并合成 PPTX/PDF。

Step 3: Deck Brief

Save deck-brief.md. Must include:

  • style_preset
  • audience
  • slide_count
  • language
  • visual_rules
  • do_not_use
  • reference_images(if any)
  • source_visual_plan: which pages use real figures/screenshots, sources, and handling methods

Read style details as needed references/style-system.md. Read the real material strategy as needed references/source-visuals.md。

Step 4: Outline

Save outline.md. Use a fixed structure for each page:

## 01. Slide Title
- Role: cover / context / method / mechanism / evidence / result / takeaway
- Message: 这一页唯一要讲清楚的观点
- Visual: 画面主视觉和构图
- Text: 页面上允许出现的短文字
- Evidence: 引用的论文图表/公式/实验数据/代码位置
- Source visual: 是否使用真实截图/论文图表;来源、裁剪范围和落位
- Repair handle: 后续返修时可引用的定位描述

Rules:

  • Each page carries only one main point.
  • Keep on-page text as minimal as possible; put complex explanations in the speaker script or notes.
  • For mechanism pages, prioritize drawing "input → processing → output"; do not draw abstract inspiration.
  • Data pages should contain only the 1-3 most persuasive numbers.
  • Real paper figures/screenshots are usually more credible than generating from scratch; when real materials can be used, prioritize planning where real materials will go.
  • Do not leave excessive blank space. The main visual, chart, or evidence area should usually occupy 60%-80% of the frame, unless it is a cover or section page.
  • 8 or more pages must have rhythm variation: cover, problem, method, mechanism, evidence, and conclusion alternating.

Step 5: Prompt Files

For each page, the prompt file must be written first, then any image generation tool may be called.

Path:

paper-deck/{topic-slug}/
├── analysis.md
├── deck-brief.md
├── outline.md
├── prompts/
│   ├── 01-slide-cover.md
│   ├── 02-slide-context.md
│   └── ...
├── images/
│   ├── 01-slide-cover.png
│   ├── 02-slide-context.png
│   └── ...
├── {topic-slug}.pptx
└── {topic-slug}.pdf

For prompt writing, read references/prompt-template.md。

Hard rules:

  • The prompt must explicitly specify 16:9.
  • The prompt must clearly state the style, composition, text language, and text quantity limits.
  • Do not let the model generate page numbers, logos, watermarks, or PPT shells.
  • If precise text is needed, minimize text within the image; a mixed text layer can be added later.
  • If this page uses real materials, the prompt must explain how the materials serve as part of the composition: embedded, cropped, carried on a glass panel, side notes, enlarged frames, rather than letting the model redraw facts from scratch.

Step 6: Generate images

Image backend selection:

  1. In the Codex environment, prioritize the built-in imagegen。
  2. If the user specifies baoyu-imagine, Gemini, OpenAI, Seedream, or other backends, follow the user's specification.
  3. If no image generation backend is available, stop and tell the user that a raster image backend is needed.

Image generation gate:

  • Before calling any image generation tool, the corresponding page's prompts/NN-*.md。
  • The main image that ultimately goes into each page must come from a real raster image generation backend. images/ The main image that ultimately goes into each page must come from a real raster image generation backend.
  • It is not allowed to use Python/Pillow, SVG, HTML/CSS, Canvas, Mermaid, matplotlib, PPT shapes, or local drawing scripts to generate a full-page main image as a substitute for image generation.
  • It is not allowed to bypass the image generation backend and switch to locally drawing the full page just because you are worried about errors in Chinese text. The correct approach is to reduce the text within the image, revise the prompt and regenerate, or, with the user's consent, use a hybrid approach of "generated image background + editable text layer".
  • If a hybrid text layer is used,images/ must still retain the generated image background or generated full-page source for each page, and in deck-brief.md record which text was overlaid afterward.
  • After generation, record in generation-log.md the backend used for each page, the prompt file, the output file, and the generation time; images without generation records cannot be used as final delivery pages.

Generation strategy:

  • First generate page 1 as the style anchor.
  • For subsequent pages, if the backend supports reference images, use page 1 as the style reference to reduce drift.
  • Check the thumbnails every 3-4 pages; if style drift is found, fix the prompt and continue.
  • Save failed pages; do not overwrite successful pages.

Step 7: Composite PPTX/PDF

After generating the images, run:

python3 <SKILL_ROOT>/scripts/merge_deck.py paper-deck/{topic-slug}

The script will read images/NN-*.png|jpg|webp, output the same-named .pptx and .pdf. Each image fills one 16:9 page.

Step 8: Quality check

Before delivery, check according to references/quality-gate.md :

  • Does it look like a real design work at a glance, rather than a pile of templates?
  • Does each page have only one main point?
  • Is there too much meaningless whitespace; does the key content occupy enough of the frame?
  • Do pages with real assets clearly record the source, page number/figure number, and placement?
  • Is the style consistent?
  • Is the text in the images clear, with no typos and no fake characters?
  • Are there common AI issues: fake UI, fake logos, garbled labels, excessive cyberpunk, plastic 3D, meaningless decoration?
  • generation-log.md Does it exist, and does every page record the real raster image generation backend, prompt file, and output file?
  • Is there any local drawing/template/screenshot pretending to be a generated image page; if so, it must be redone or explicitly changed to a non-paper-deck route confirmed by the user?
  • Can the PPTX/PDF be opened, and is the page count correct?

Step 9: Rework

When reworking, always modify the source files first:

The user says Action
"Make page 5 more academic" Modify prompts/05-*.md, keep the old image, generate a new image
"Unify it to the texture of page 1" Append the page 1 style anchor to the relevant prompts
"Page 7 has too much text" Modify the Text in the outline, then modify the prompt
"Only redo the background, do not touch the content" Keep the Message/Text in the prompt, rewrite the Visual
"Add a page of mechanism details" Update the outline, add a new prompt, generate the image, rerun the compositing script

Do not use a program to alter text on the generated image. If the text is wrong, modify the prompt and regenerate, or switch to the hybrid text layer approach.

Reference files

  • references/style-system.md: Style presets and selection rules
  • references/layouts.md: Common page roles and composition
  • references/source-visuals.md: Usage strategies for PDF screenshots, paper figures, and user images
  • references/prompt-template.md: Per-page image generation prompt template
  • references/quality-gate.md: Pre-delivery checks and rework standards