Journal Club Slides

intent

use this skill to convert one or more research paper PDFs into a presentation-ready journal club or literature-report deck. the standard is not "extract paper content into ppt". the output must be faithful to the paper's argument, optimized for live speaking, visually strong enough to present directly, figure-first rather than text-first, grounded in real main and supporting evidence, and verified through rendered output (not just source form). use this when the user wants slides that follow the paper's logic, pair figures with same-conclusion supporting evidence correctly, preserve figure integrity through safe cropping, speak to the audience (not the author), and pass render-based QA. do not use this for teaching decks that need major textbook pedagogy beyond the paper itself, simple abstract-only summaries with no figure work, or business decks where paper-figure integrity is not the central constraint.

inputs

• PDF files: one or more research papers in PDF format. include supplementary materials PDFs if available and referenced in main paper.
• paper text extraction: abstract, introduction, results section, figure legends, supplementary legends, and conclusions. extract via pdf text layer (preferred) or OCR if text layer unavailable.
• rendered page images: high-resolution page images from the PDF (min 150 dpi, ideally 300 dpi) for crop work and figure verification. generated from the PDF itself, not screenshots.
• supplementary figure files: separate supplementary PDFs or image files if the journal hosts them separately from the main PDF.
• user intent and scope: clear statement of what the deck should cover (full results chain, selected results, narrative structure, bilingual requirements if any).
• external tools (local or cloud, depending on environment):
  • pdf extraction library (e.g. pdfplumber, pymupdf, or cloud API like CloudConvert).
  • image rendering (e.g. pdf2image, ghostscript, or online pdf-to-image tool).
  • powerpoint generation library (e.g. python-pptx for local; Office 365 API or similar for cloud).
  • optional: OCR tool (e.g. tesseract, paddleocr) if paper lacks text layer or bilingual text needs extraction.
• bilingual support (if needed): confirm that the target powerpoint environment has the required font stack (e.g. SimSun or Noto Sans CJK for Chinese; Arial or Calibri for Latin). if fonts are missing, add them to the environment or use a fallback font family before deck generation begins. treat missing bilingual fonts as a blocker, not a cosmetic issue.
• render environment access: if possible, access to a way to export slides as PDF or high-res images for QA (e.g. LibreOffice, Office 365, or command-line tool like libreoffice --headless --convert-to pdf). not mandatory but strongly preferred.

procedure

step 1: build a paper workspace

create a project folder with these subdirectories:

• source/: original PDF(s) and supplementary PDFs.
• extracted/: text extractions (abstract, results, legends, conclusions).
• images/: rendered page images from the PDF.
• figures/: cropped figure assets (organized by result/figure number).
• scripts/: any python, bash, or other automation scripts for image processing or pptx generation.
• qa/: rendered output (PDF exports, screenshot archives) for QA verification.

input: project folder structure. output: a workspace ready to receive extracted text, page images, and figure crops.

step 2: extract text and page images in parallel

text extraction track:

• use pdf text extraction (pdfplumber, pymupdf) to pull the text layer.
• if text layer is broken or missing, run OCR (tesseract, paddleocr).
• extract and separate: abstract, introduction/problem framing, results section with figure numbers, figure legends (including panel descriptions), supplementary legends, conclusions, author affiliations, journal/doi.
• save to extracted/paper-text.md or extracted/paper-text.txt with clear section headers.

image extraction track:

• render all pages of the PDF to high-res images (150-300 dpi, png or jpg format).
• save to images/page-NNN.png (zero-padded).
• render supplementary PDFs separately to images/supp-page-NNN.png.
• confirm image count matches page count in the PDF.

input: PDF file(s), extraction tools, OCR environment (if needed). output: extracted/paper-text.* and images/page-*.png (all pages) plus images/supp-*.png (if supplementary PDFs exist).

step 3: map questions, figures, and supporting evidence

before designing slides, create an explicit argument map (as markdown or spreadsheet):

• for each major result figure in the paper, note:
  • figure number (e.g. fig 1a, fig 2bc).
  • the question or claim it answers (e.g. "does protein X localize to the nucleus?").
  • the main quantitative or visual finding.
  • which supplementary or extended-data figure supports the same conclusion (by reading figure legends and result text, not by page proximity).
  • where this result sits in the paper's narrative order.
• for review or framework papers, map conceptual figures the same way (framework diagrams, field maps, mechanism schematics).

input: extracted text (legends, results section, supplementary legends). output: extracted/argument-map.md or extracted/argument-map.csv linking each major figure to its question, conclusion, and supporting evidence.

step 4: write slide logic before layout

for each results slide you plan to create, define (as notes or structured text):

• the title question or direct claim (audience-facing).
• what the main figure proves.
• what the support figure validates (or null if no support figure exists).
• the most important quantitative or conceptual takeaway (one sentence).
• how this slide transitions from the previous one or bridges sections.

input: argument map from step 3. output: extracted/slide-logic.md with one section per result slide, listing title, main figure, support figure, key finding, and transition note.

step 5: extract figures conservatively

for each figure designated in the argument map:

• locate the figure on the rendered page image (from step 2).
• identify the figure boundary and all panel labels (a, b, c, etc.), legends, scale bars, axes, color bars, tick labels.
• crop to include the entire figure body plus a small margin (5-10 pixels) around the boundary. never crop into:
  • panel letters or panel borders.
  • axis titles, tick labels, or numeric scales.
  • legends, color bars, or scale bars.
  • workflow arrows, result labels, or right/bottom-edge annotations.
• prefer a slightly larger crop with safety margin over a tight crop that risks clipping content.
• do not stretch figures: preserve original aspect ratio when cropping and at placement time.
• save crops as high-quality png or jpg to figures/figure-NNN.png and figures/supp-NNN.png.
• for dense Nature/Cell/Science-style pages, remove dead margin (blank page edges) before cropping the scientific content. do not shrink the figure itself.
• for review or framework figures, verify that the crop is the real figure body (diagram, schematic, chart), not a text-heavy page with minor illustration. if the "figure" is mostly text, reconsider whether a text box or smaller crop is appropriate.

input: rendered page images, argument map, figure legends. output: cropped figure assets in figures/figure-*.png, indexed by figure number.

step 6: design slides for clarity and impact

for each result slide:

• place the main figure prominently (not a small thumbnail).
• if a same-conclusion support figure exists (from argument map), place it on the same slide at comparable visual weight to the main figure (not a tiny thumbnail).
• add audience-facing explanatory text (one to three sentences) that states what the figure shows, why it matters, and how it advances the paper's logic. remove any creator-facing labels such as "take-home", "reading note", "interpretation", "speaker hint", or "this slide wants to show".
• use clean white or near-white background (unless user requests otherwise).
• prefer restrained accent colors (one or two carefully chosen) over heavy shadows, thick borders, or dashboard-style framing.
• increase figure footprint before shrinking figures into illegibility.
• create one clear visual center per slide (usually the main figure).
• if a figure pair is too dense to read on one slide, split the content across two slides rather than shrinking both into invisibility.
• if support evidence remains unreadable at slide scale, re-crop the support asset (tighter, larger, or with better contrast) or redesign the support area.
• maintain hierarchy: titles should be readable from the back of the room (min 32pt for live projection), explanatory text readable from mid-room (min 20pt).
• for bilingual decks, ensure both languages are readable at the same scale and visual weight.

input: cropped figures, slide logic, design guidelines (white background, academic style, no dashboard chrome). output: draft slide layouts in the powerpoint file with all result slides present and figure pairs correctly placed.

step 7: structure the full deck

assemble slides in this typical order (adapt for paper type):

1. cover slide: title, authors, affiliations, journal/doi, date.
2. introduction or problem-framing slide: context, why this question matters.
3. methods or approach slide (optional): brief overview if not obvious from results.
4. result slides in paper order: one per major finding, with main + support figures and audience-facing explanation.
5. strengths, limitations, implications slide: critical takeaways.
6. summary or conclusions slide: one-sentence main message.

for review papers or multi-paper decks:

• replace results-driven progression with conceptual structure (framework first, field tensions, future directions).
• if combining multiple papers, build one integrated storyline with explicit transition slides and a shared biological or conceptual question. exclude unrelated papers even if they were in the source folder.

input: draft result slides from step 6, cover/intro/summary content. output: complete .pptx file with all slides in narrative order.

step 8: run render QA

export the .pptx to PDF or high-resolution slide images (using LibreOffice, Office 365, or command-line tool like libreoffice --headless --convert-to pdf deck.pptx). visually inspect the rendered output for:

• title and text rendering: no overflow, no clipped headers, no tofu boxes (garbled CJK characters).
• fonts: confirm bilingual fonts render correctly if used. if fonts are missing, this is a blocker (go back to step 6 and fix the font environment).
• figure quality: no distortion, no unexpected stretching or squashing.
• figure-to-legend correctness: confirm each figure image matches its intended figure number and panel labels.
• support panel readability: support figures must be readable at slide scale, not technically present but visually useless.
• creator-facing labels: confirm no "take-home", "interpretation", "speaker note", or similar scaffolding remains.
• decorative artifacts: check for unintended shadows, borders, clipped shapes, or leftover design elements from editing.
• blank panels: confirm no empty text boxes or placeholder slides remain from late edits or language fallbacks.

input: rendered PDF or slide images from .pptx export. output: QA checklist noting any issues found (issue type, slide number, severity).

step 9: fix and re-render

if render QA finds problems:

• return to the .pptx source.
• patch the issue (e.g. re-crop a support figure, fix a text overflow, add missing font, remove a creator label, adjust figure scale).
• regenerate the rendered output and re-inspect.
• repeat until the rendered deck passes all QA checks.

at least one fix-and-verify loop is expected for serious paper decks. do not stop at the first generated deck.

input: QA issues from step 8, edited .pptx source. output: patched .pptx file and verified rendered output with all issues resolved.

decision points

• if bilingual rendering fails (missing fonts, broken CJK, etc.): stop immediately and fix the font environment. do not proceed with a half-working deck. either add the required fonts to the system/project or use a fallback font family deliberately and consistently. treat this as a blocker, not a cosmetic issue.

• if supplementary figures exist in a separate PDF: render and crop them the same way as main-paper figures. use them over summary text boxes when mapping supporting evidence. if supplementary images are difficult to obtain (paywalled, archived, or only available as figure captions), note this in the argument map and use a text summary box only as a deliberate fallback, not as the default.

• if a "figure" in the paper is actually a text-heavy table, workflow diagram, or dense text block: do not force it into a results slide. instead, extract only the essential visual element (actual figure, diagram, or key table) and pair it with minimal text. if no clear visual element exists, consider whether that result deserves a dedicated slide or should be merged with an adjacent result.

• if a dense figure is unreadable at slide scale (e.g. Nature/Cell multi-panel with tiny subtext): do not shrink it further. instead, split the figure across two slides (one for main panels a-c, one for panels d-f, each with its own explanation) or re-crop the figure to show only the most critical panels and explain the rest in text. readability is non-negotiable.

• if support evidence cannot be obtained or is truly absent: use a concise text summary (one or two sentences, audience-facing, not creator scaffolding) instead. flag this in QA notes so the user knows that evidence pairing was attempted but fell back to summary text.

• if the paper is a review, conceptual framework, or multi-paper synthesis: do not force it into a results-only template. instead, map the argument as conceptual progression (framework introduction, field tension, conceptual resolution, future directions) and structure slides around that logic. treat framework diagrams and future-direction figures with the same rigor as experimental results.

• if rendering tools are unavailable (no LibreOffice, no cloud export API, no offline conversion tool): note this as an environment constraint in the delivery checklist. render QA is strongly preferred but not mandatory if the environment truly lacks all conversion options. if export is possible later, plan a deferred QA pass.

output contract

the final deliverable is a .pptx file with:

• slide count: typically 8 to 15 slides for a single paper (cover, intro, 4-8 result slides, strengths/limitations, summary).
• slide structure: cover, introduction/framing, results (one or more per major finding), strengths/limitations, summary.
• each result slide contains:
  • a clear question or claim as the title (audience-facing).
  • main figure (large, readable, undistorted, with correct aspect ratio).
  • same-conclusion support figure (if available, at comparable visual scale).
  • concise explanatory text (1-3 sentences, no creator scaffolding, bilingual if requested).
  • clean white or near-white background with minimal framing.
• visual consistency: all slides follow the same font, color, and layout hierarchy. titles are large and readable. text is 20pt minimum for live projection. figures are high-quality and properly cropped.
• figure integrity: all figures are cropped safely (no clipped axes, legends, scale bars, or labels). aspect ratios are preserved. support figures are readable at slide scale.
• no creator-facing labels: no "take-home", "interpretation", "speaker hint", or similar scaffolding in the final deck.
• render-verified output: either the .pptx itself (if render tools unavailable) or a rendered PDF/slide-image set (if export is possible). QA checklist confirming all checks passed.
• argument map and slide logic (as reference, not part of the deck): extracted/argument-map.md and extracted/slide-logic.md documenting the decision path.
• file locations:
  • .pptx output: <project-root>/deck.pptx or user-specified path.
  • rendered QA output (if available): <project-root>/qa/deck.pdf or <project-root>/qa/slide-*.png.
  • source assets: <project-root>/figures/figure-*.png, <project-root>/extracted/*.md.

outcome signal

you know the skill worked when:

• the final deck is ready to present to a journal club or lab meeting without further editing (or with only minor speaker-note additions, not slide content changes).
• a speaker can pick up the deck and understand the paper's logic and key findings from slide titles, figures, and explanatory text alone.
• figures are readable from the back of a medium-sized meeting room (min 32pt titles, readable support panels).
• each major result in the paper is represented by one or more slides with main figure plus same-conclusion support evidence.
• no creator-facing labels or scaffolding remain on any slide.
• all rendered output (PDF, images, or live slideshow) shows correct fonts, undistorted figures, no clipped content, and correct figure-legend pairing.
• the user can point to the final deck and confirm it matches the paper's narrative order and argument structure.
• if render QA was run, all issues from the checklist are resolved and documented as closed.