SuperAPI AI Directory

research-presentation-slides

Office & productivity

View repository

Updated 10-15 09:45

About this skill

Research presentation slides

This skill specifiesthe process and standards for making good work-presentation slides. It does not care what tool is used; tool-level operations are left to the corresponding tool's skill or documentation (e.g., pptx skill, Beamer documentation).

One premise: a talk is meant to be "heard", and slides are辅助. Slides are not a script, nor a compressed version of a paper. Every step below carries out this premise.

Workflow

Do it in order. Each step produces a file, and the next step takes it as input. Do not skip steps 1–3 and go straight to making pages; that is the most common cause of bad slides.

Step Output Template / Tool Details
1. Set the goal talk-brief.md assets/talk-brief-template.md references/planning.md
2. Build the storyline storyline.md assets/storyline-template.md,scripts/lint_storyline.py references/structure.md,references/talk-types.md
3. Write the page-by-page spec slide-specs.md assets/slide-spec-template.md references/slide-design.md,references/figures.md
4. Produce Source file (.pptx / .tex / .md / …) The tool chosen by the user references/visual-style.md
5. Export and check deck.pdf + check report scripts/check_deck_pdf.py "Step 5" of this document
6. Review and fallback Revised deck, backup pages, speaker notes references/review-checklist.md references/delivery.md

Step 1: Set the goal → talk-brief.md

Copy assets/talk-brief-template.md and fill it in: purpose, audience,one-sentence core message, duration, occasion constraints.

  • When any of duration, audience, or occasion is missing:humansfill it in themselves;agent ask the user first, and if you cannot get an answer, write the assumptions clearly into the brief and tell the user when delivering.
  • The core message must be a complete declarative sentence, not a topic. For example, "X method" is a topic; "X halves inference latency without losing accuracy" is a core message.

Step 2: Build the storyline → storyline.md

Copy assets/storyline-template.md。Write each page as a one-line conclusion sentence, and tag it with a role label. The planning order isworking backward from the results:

  1. Group the results by "which point does it support", into 2–4 groups, and each group yields one main point. Do not group by the order in which the experiments were done.
  2. Results that do not support these points should be deleted or moved to [backup]。
  3. The methods section only needs to go as far as the audience can understand the results.
  4. Finally, write the opening motivation: start from a question that all audience members care about, and connect it to your specific goal.
  5. The ending returns to that big question and restates the core message. The last page's main content cannot be just "Thank you" or "Questions?".

Then run:

python scripts/lint_storyline.py storyline.md

Fix until there are no ERRORs. Finally,read only the titles, and read through them from start to finish: reading them should form a coherent story. If it does not read smoothly, revise the storyline; do not proceed to the next step.

agent: show the core message and title list to the user first (or list them in the reply), and only generate pages after confirming the direction.

Step 3: Write the page-by-page spec → slide-specs.md

For each page in the storyline, write clearly according to assets/slide-spec-template.md : title (conclusion sentence), visual center (which image/diagram), the small amount of text on screen, what to say (speaker notes), source citations, estimated duration. See the rules in references/slide-design.md and references/figures.md。

Step 4: Production

Using the tool selected by the user, turn the specification into pages. See the visual guidelines in references/visual-style.md. For tool-related operations, see the corresponding tool's skill or documentation.

Step 5: Export PDF and check

Almost all tools can export PDF, so checks are uniformly done on the PDF:

python scripts/check_deck_pdf.py deck.pdf --duration 15 --backup-start 18 --render pages/
  • Dependencies:pip install pdfplumber pypdfium2(--render requires the latter).
  • Script checks: whether page count and duration match, whether font size is too small, word count per page, text-only pages, whether content exceeds the page, number of fonts, page numbers. For parameter descriptions, see --help。
  • --render export each page as PNG.Look at the images page by page, and check for issues that scripts cannot catch: overlap, truncation, blurry images, insufficient contrast, alignment. The agent must do this step: code compiling successfully does not mean the layout is correct.
  • Fix all ERRORs. Judge WARNs one by one: either fix them, or be able to state the reason for not fixing them.

Step 6: Review and fallbacks

  • Go through references/review-checklist.mditem by item, with numbered items (for example S3、F2). When writing review comments, cite the numbers.
  • Complete according to references/delivery.md : backup pages, speaker notes, PDF fallback version, video screenshots, skip plan for when running overtime.
  • Human: do one full timed run-through, and return to steps 2–3 to revise pages that run overtime or do not flow well.

Inviolable rules

These rules hold in any situation. For other rules, see references, and choose according to the occasion.

  1. One page covers only one point; content page titles state the conclusion, not the topic.
  2. You will talk about everything on the screen; do not put up what you will not talk about.
  3. Each page has a visual center; do not write long complete sentences.
  4. Text must be large enough to be readable under projection; text in charts is the same.
  5. Data, results, and citations may only come from materials provided by the user or verifiable sources. If missing, leave an obvious placeholder (for example 【待补:xx 实验数字】) and tell the user. Never fabricate.
  6. First have the core message and storyline, then make the pages.

Rewrite or review existing slides

  1. Export or obtain the PDF, run scripts/check_deck_pdf.py。
  2. Infer from the existing pages storyline.md(rewrite each page title as a conclusion sentence), run lint_storyline.py。
  3. Use references/review-checklist.md to output a numbered issue list, sorted from greatest to least impact: structural issues > single-page issues > visual issues.
  4. When revising, change the storyline first, then change the pages.

Directory structure

research-presentation-slides/
├── SKILL.md                    # 本文件:工作流 + 索引
├── references/                 # 各步骤细则,按需读取
├── assets/                     # 第 1–3 步的模板(复制后填写)
├── scripts/
│   ├── lint_storyline.py       # 检查 storyline.md
│   └── check_deck_pdf.py       # 检查导出的 PDF,可渲染逐页 PNG
└── evals/evals.json            # 测试用例,修改 skill 后用来回归

References index

Read when needed; no need to read everything at once:

  • references/planning.md: how to determine purpose, audience, and core message; common mistaken goals.
  • references/structure.md: hourglass structure, reasoning backward from results, newspaper-style argumentation, nested layers, opening and ending, where to put the literature review.
  • references/talk-types.md: trade-offs and duration allocation for different occasions (short conference talk, group meeting, defense, job talk, lightning talk, non-expert audience).
  • references/slide-design.md: single-page rules, with before-and-after rewrite examples.
  • references/figures.md: how to adapt figures and tables from the paper version to the slides version.
  • references/visual-style.md: font size, color scheme, fonts, accessibility, consistency.
  • references/delivery.md: speaker notes, practice, backup slides, technical failure contingency plans.
  • references/review-checklist.md: a numbered review checklist, and also the final check before delivery.
  • references/sources.md: the materials on which this skill is based.

Extending this skill

  • Add a new occasion(for example grant pitch, product review): in references/talk-types.md , add a section with the same format as the existing sections (purpose / duration allocation / required slides / common mistakes).
  • Add a new rule: put it into the reference file for the corresponding topic, and at the same time add a new numbered item in references/review-checklist.md . Do not change existing numbers, so as not to break old review records.
  • Add tool-related notes(for example Beamer theme suggestions): create references/tools/<tool>.md, and add a line in the index above. Keep this file tool-agnostic.
  • Add automated checks: extend in scripts/ . Try to check tool-agnostic artifacts such as PDF or storyline.md , and add the corresponding test cases in evals/evals.json .