Beamer

Beamer Slide Generator

Generate an original Beamer presentation from source content (structured notes, summaries, or raw material). This skill handles the full cycle: structure and register triage, outline checkpoint, code-first figure generation, design, authoring the .tex file, compilation, and verification through multi-agent review.

Six additions from Scott Cunningham's beautiful_deck approach are integrated: code-first figures (matplotlib), an outline checkpoint, structure-aware rhetoric, Devil's Advocate slides, code blocks, and transition slides.

Beyond generating a new deck, the skill also works on an existing one through three additional modes (edit, audit, and convert-to-PPTX); see Mode Selection below. Edit mode auto-activates when the current working directory already contains a *_build/slides.tex.

Input

This skill expects one or more of:

• A notes.md file with structured extraction from a deep reading (for example, from ../split-pdf/SKILL.md)
• A summary.md file with a structured summary
• Raw content, pasted text, or other source material

Two optional parameters tune the deck. structure= selects a domain pattern from domain_patterns.md: mba (the default), teaching, faculty, professional, consulting, or working. register= selects the language level: business (the default) translates or glosses the source's domain jargon for a non-specialist reader; technical keeps the source vocabulary intact. The legacy audience= parameter is accepted as a deprecated alias for structure= with the same value set.

If invoked standalone, ask the user what content to build slides from. If invoked as part of a slides workflow, notes and summary files will already exist in the working subdirectory.

Working Directory

Save all output files in the current working subdirectory. If no subdirectory has been established, create one named after the source material (for example, slides_smith_2024/).

If figures are extracted from the source PDF, save them to figures/ inside the working subdirectory, with original full-page renders in figures/originals/.

Mode Selection

Default mode: generate (build a new deck from source content). This skill also supports three additional modes for working with an existing deck. Generate-mode behavior is unchanged whether or not callers pass a mode= argument.

Edit mode activates when ANY of the following is true:

• The invocation includes mode=edit.
• The user invoked via an edit, revise, or fix trigger ("edit beamer", "revise beamer", "fix beamer slides", "update beamer deck").
• The current working directory contains a *_build/slides.tex and no mode=generate was passed.

Audit mode (mode=audit, or an audit trigger) re-runs the Quality Audit pass against an existing compiled deck. No content edits beyond audit-fix remediation. Use when revisiting a deck after a long pause, or to confirm a previously generated deck still passes the checklist.

PPTX mode (mode=pptx, or a "convert to pptx" trigger) runs only the PPTX conversion block against an existing compiled deck. No audit, no edits.

In any non-generate mode: skip everything from Step 0.1 through Figure Extraction (Step 0.1 Pre-flight Deliverable Check, Step 0.5 Structure and Register Triage, Step 0.6 Citation Strategy, Step 0.7 Outline Checkpoint, Step 0.8 Code-First Figure Generation, Design Requirements, Content Requirements, Visual Mechanism Selection, Number Formatting, Acronyms and Abbreviations, Quality Standards, Figure Extraction). All of these are generate-time prep that does not apply to a previously generated deck. Jump from Step 0 (LaTeX verification) directly into the Edit Mode section below for the locate and load-context steps, then dispatch per the chosen mode. The Edit Mode E2 step is the entry-point backup counterpart to Step 0.1; running both would produce duplicate timestamped backups.

In generate mode: proceed with every step as usual. There is no behavior change for workflows that call this skill in generate mode.

structure= and register= in non-generate modes: both parameters only take effect in generate mode (via Step 0.5 Structure and Register Triage). In edit, audit, or pptx mode, both are silently ignored; the deck's structure and register were set at generate time and are not reconfigurable mid-flight. To use a different structure, regenerate the deck from scratch with mode=generate. (audience= is the deprecated alias for structure= and is ignored here too.)

Auto-detection ambiguity: if the CWD contains multiple *_build/slides.tex subdirectories, auto-detection still fires (edit mode is chosen), and Step E1 below prompts the user to pick which deck.

Trigger vs CWD-auto-detect precedence: if the user invokes via an explicit generate trigger ("create beamer slides", "generate beamer deck", "make latex slides", "beamer presentation from this") AND new source content is provided in the same turn, run generate mode even if the CWD contains a *_build/slides.tex. Auto-detect only fires when the invocation is ambiguous (no explicit trigger family, or no source content). Rationale: a user who explicitly asks to create new slides in a directory that happens to already contain a deck is starting a second deck, not editing the first.

Edit Mode

This section runs when the skill is invoked in edit, audit, or pptx mode (per Mode Selection above). It performs the locate-and-load steps, presents the menu when in edit mode, and dispatches into the relevant Compilation Cycle and Output blocks. Skip this entire section in generate mode.

E1: Locate the Output and Build Subdirectories

The base directory is the current working directory at the time the skill is invoked.

If the user specifies a file or folder name:

• If the user provides a source file name (for example, smith_2024.pdf), look for the matching output subdirectory (for example, smith_2024/) and its build subdirectory (for example, smith_2024/smith_2024_build/).
• If the user provides a subdirectory name directly (for example, smith_2024), use that as the output subdirectory and look for <name>_build/ inside it.

If no name is provided: list the subdirectories in the current working directory that contain a *_build/slides.tex file. If exactly one is found, use it. If multiple are found, present the list and ask the user to pick. If none are found, report the error and stop.

Validation: confirm that slides.tex exists in the build subdirectory. If it does not, report the error and stop.

E2: Pre-flight Deliverable Check (entry-point version snapshot)

Before loading context or applying any edits, preserve the deck being edited as a version snapshot. This start-of-round capture fires here at entry and again at each E8 loop-back (once per edit round).

1. Version-snapshot the deck. The deck about to be edited is the current compiled deck <build>/slides.pdf, paired with its source <build>/slides.tex. If it exists, preserve it as the next milestone:
   • Glob existing <content_name>_slides v*.pdf in the output subdirectory. Next N = highest existing vNN + 1, zero-padded to two digits; if none exist, N = 01. Generation writes no vNN, so the first edit creates v01, the backup of the generated deck.
   • Snapshot suffix:
     • v01 (no prior vNN): the deck being preserved is the generated baseline. Suffix = v01 structure-<x> register-<y>, where <x>/<y> are the structure and register the deck was generated with, read from the deck's generate-time entry in the project session log (CLAUDE.local.md if you keep one). If no record exists, use structure-mba register-business and say so in the report.
     • v02+: suffix = v0N <label>, a 1-3 word descriptor of the change that defined the version being preserved. For an in-conversation E8 loop-back, derive the label from the edits just applied in that round.
   • Copy the PDF: cp "<build>/slides.pdf" "<output>/<content_name>_slides <suffix>.pdf". (Fallback: if <build>/slides.pdf is absent but the output deliverable exists, copy <output>/<content_name>_slides.pdf.)
   • Copy its source, paired: cp "<build>/slides.tex" "<build>/slides <suffix>.tex", so the version recompiles and diffs, not only views. The .tex must be taken now, before this round's edits overwrite it in place.
2. Version-snapshot the PPTX (if present), per Output's "PPTX version snapshots (vNN)": if <content_name>.pptx exists and is not already byte-identical to the newest <content_name> v*.pptx (cmp -s), snapshot it as the next vNN. If it is already preserved as the latest vNN, do nothing.

Report: "Snapshotted the deck being edited as <content_name>_slides <suffix>.pdf (+ source slides <suffix>.tex)."

One snapshot per edit round (one batch of changes the user reviews): here at entry, and again at each E8 loop-back. Intra-round audit-fix recompiles do not snapshot. This is the safety net: every delivered version is preserved before the next round overwrites it.

Convention recap: <content_name>_slides.pdf is always the latest; the vNN files are the preserved version history beneath it, each paired with its slides vNN ....tex source in _build/. v01 is the backup of the generated deck (made at the first edit), tagged with the deck's structure and register; later versions carry change-labels. After N edit rounds there are N vNN files; a count short of the rounds applied means a snapshot was skipped.

If no deck exists yet (no <build>/slides.pdf and no deliverable), proceed silently.

E3: Load Context

Read the following files (silently skip any that do not exist):

From the build subdirectory (<name>_build/):

1. notes.md: deep-reading extraction notes
2. slides.tex: the current Beamer source
3. figures/: if this directory exists, note it silently. The existing figures are available for reference in the .tex source; do not move or rename them. If the user's edits require adding new figures from the source PDF, follow the Figure Extraction protocol later in this skill (pdftoppm at 300 DPI, PIL crop, save to figures/, originals to figures/originals/).

From the output subdirectory: 4. <content_name>_summary.md: structured summary (filename matches the output subdirectory name)

Do not load the PDF at this stage. The compiled PDF is only needed for the quality audit. If the dispatched path requires it (audit mode, or edit-mode menu option 2), load it then, gated to the four-page rule: if the compiled deck is 4 pages or fewer, read it directly in the main thread; if it is more than 4 pages, do not read it in the main thread. The Compilation Cycle Step 3 audit agent reads the full compiled PDF itself inside a subagent, so the main thread does not need the page images at all; hand off to Step 3 without a main-thread read. For all other paths, slides.tex is sufficient.

E4: Mode Dispatch

Branch on the active mode:

• mode=audit: jump directly to Compilation Cycle Step 3 (Quality Audit), which loads the full compiled PDF itself inside its audit subagent; no main-thread PDF read is needed here. After Step 4 (Fix and Recompile) completes, proceed to Output. Skip the menu in E5.
• mode=pptx: jump directly to the Output section's PPTX conversion block. Skip the menu in E5.
• mode=edit: continue to E5.

E5: Present Menu (edit mode only)

After loading context, pause and present this menu to the user:

"Loaded slides for [title]. The deck has [N] slides. Available context: [list which of notes.md, summary.md, slides.pdf were loaded]

What would you like to do?

1. Edit the slides: make content, layout, or style changes and recompile
2. Run the quality audit: read the compiled PDF slide-by-slide and report visual or formatting issues
3. Convert to PPTX: convert the existing compiled PDF to a styled PowerPoint file
4. Something else: describe what you need"

Wait for user response. Then route:

E6: Response Discipline (edit mode only)

When the user reports a visual problem, defect, or issue with the slides:

1. Read the relevant slides in the compiled PDF to verify the problem, gated to the four-page rule. If the compiled deck is 4 pages or fewer, read it directly in the main thread. If it is more than 4 pages, do not read it in the main thread: split it into 4-page chunks with the split-pdf skill and launch a subagent to read the chunk(s) covering the reported slide(s). Instruct the subagent to return slide-level detail (for each slide in scope: the slide title, the verbatim text, numbers, and labels involved, and a concrete visual description of the defect, namely what overlaps, clips, overflows, or is mispositioned, and where on the slide), not a one-line summary. You need enough fidelity to locate and fix the exact element in slides.tex.
2. Describe what you found and propose a specific fix.
3. End with a question: "Should I apply this fix?" or "How would you like to handle this?"
4. Do not edit slides.tex in the same response. Wait for the user's approval before making any file changes.

This applies whether the problem was reported via screenshots, verbal description, or discovered during the quality audit. The user may want to handle the fix differently, redirect to a different priority, or provide additional context that changes the approach.

E7: Apply Edits (edit mode only)

Apply the user's requested edits to slides.tex in the build subdirectory. Follow the Beamer style guide at ../../style-guides/beamer/style-guide.md for all design decisions. Read it before making any edits if not already loaded. Use the loaded notes.md (from build) and <content_name>_summary.md (from output) as source material when the user asks to add, expand, or rework content.

Edit types (handle any combination):

• Content changes: add, remove, reorder, or reword slides or bullet points
• Figure or chart changes: modify TikZ diagrams, pgfplots charts, data values, labels, colors
• Layout changes: split dense slides, merge sparse slides, change column widths
• Style changes: adjust colors, fonts, spacing (within the style guide)
• Structural changes: add new slides, remove slides, change slide order

After edits are written, proceed to Compilation Cycle Step 1.

E8: Iteration Prompt (edit mode only)

After Compilation Cycle Step 4 completes in edit mode, before proceeding to Output, ask:

"Edits applied and recompiled. Would you like to make further changes, or are you done?"

• If the user requests more edits (or an audit, or any further change to the deck): this is a new edit round. First re-run the E2 version-snapshot step to preserve the round just reviewed as the next vNN (PDF + paired .tex), then loop back to E5 (or E6 if a specific problem is reported). Re-firing the snapshot here, once per round, is the load-bearing rule: skipping it is the version-snapshot miss this guards against.
• If the user is done: proceed to Output and stop after the deliverable PDF copy.

Do not raise PPTX in this prompt. PPTX is offered at most once, at the end of the turn that first delivers the deck, and is never re-asked across edit iterations or later turns. If the user wants PowerPoint, they will ask ("pptx this deck") or pass mode=pptx, which routes to the Output PPTX conversion block at any time.

This iteration prompt does not fire in generate, audit, or pptx modes.

Step 0: Verify LaTeX Installation

Before doing anything else, confirm that LaTeX and Beamer are installed and available in the PATH.

Set up PATH for TeX

MacTeX installs to /Library/TeX/texbin. Claude Code sessions may not have this in the PATH by default. Always run this first:

export PATH="/Library/TeX/texbin:$PATH"

Then verify:

which pdflatex && pdflatex --version | head -1 && kpsewhich beamer.cls

If pdflatex is still not found

Check alternate locations:

ls /Library/TeX/texbin/pdflatex 2>/dev/null
ls /usr/local/texlive/*/bin/*/pdflatex 2>/dev/null

If TeX binaries exist at a different path, add that path to PATH instead.

If no TeX installation is found at all, stop and tell the user:

"LaTeX/MacTeX is not installed on this machine. Please install it by running these commands in your terminal:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install --cask mactex

Then restart and try again."

Do not attempt to install MacTeX from within the agent because it requires sudo and interactive password entry.

If everything is already installed

Proceed silently. Do not report to the user unless there was a problem.

Step 0.1: Pre-flight Deliverable Check

Before writing any .tex file or compiling, check for existing deliverable PDFs that would be overwritten:

1. Check the parent directory (one level above the build directory) for any *_slides.pdf file.
2. Check the build directory for existing slides.pdf or slides_tmp.pdf.

If any deliverable PDF already exists, create a timestamped backup (cp "<file>" "<file_without_ext> YYYY-MM-DD-HHMMSS.pdf") before proceeding, and report: "Backed up existing deliverable: [filename]"

If no deliverables exist, proceed silently.

This step is non-negotiable. Overwriting a deliverable without backup destroys work from previous sessions that may not be recoverable.

Version snapshots (vNN) are an edit-mode behavior (Edit Mode E2 entry and each E8 loop-back, one per edit round), not generate mode. Generation writes no vNN; it uses the timestamped backup above and creates only <base_name>_slides.pdf. The first vNN is created at the first edit, as the backup of the generated deck (v01).

Step 0.5: Structure and Register Triage

This step resolves two independent axes and reports both.

Structure axis (structure=, the deck shape).

1. Resolve the structure value:
   • No structure= and no audience=: mba (the default).
   • structure=mba, or the deprecated aliases academic / default, or audience= naming any of those: mba.
   • structure=<value> or audience=<value> naming teaching, faculty, professional, consulting, or working: that structure. (audience= is the deprecated alias for structure=; same value set.)
   • Any unrecognized value: fall through to mba. This preserves callers that pass level words such as Executive MBA or undergraduate; those are not structural tokens and resolve to the default.
2. Read domain_patterns.md (in this skill's directory) and load the resolved structure's entry:
   • mba (and aliases / unrecognized values) maps to MBA / Executive (default)
   • teaching or lecture maps to Teaching Lecture
   • faculty maps to Faculty Development
   • professional maps to Professional Audience
   • consulting or workshop maps to Consulting Workshop
   • working maps to Working Deck
3. Apply that entry's structural template, rhetoric balance (logos/ethos/pathos), slide-count range, density, Devil's Advocate inclusion, code block inclusion, and transition slide inclusion throughout all subsequent steps.

Register axis (register=, the language level).

4. Resolve the register value: no register= resolves to business (the default); register=technical resolves to technical. Record it; it governs the domain-translation rule and the audit checklist's Content Quality #14.
   • register=business (default): the reader is a business or executive audience, not a specialist in the source's field. Translate or gloss every domain term on first use, state each chart's metric and baseline in the audience's words, and keep a translated term consistent across the deck. Content Quality #14 (the register and translation scan) is enforced at audit time.
   • register=technical: the reader is a specialist; keep the source's domain vocabulary. The translation rule and Content Quality #14 are suppressed.

Structure and register are separate axes. The default deck pairs an academic-shaped structure (mba) with a business register; the academic structure does not imply a technical register. A scholarly, keep-the-jargon deck is register=technical on whatever structure.

5. Report to the user which pattern is active:

"Structure: [entry name] (from invocation, or default mba). Register: [business|technical]. [One-line summary of rhetoric balance and slide count range from domain_patterns.md]."

Step 0.6: Citation Strategy Decision

Before reading the style guide or writing any content, determine and state the deck's citation pattern:

• Single-source (one paper, report, or dataset drives 80 percent or more of content slides): the title slide carries a "Based on [Author. Year. Title. Publication.]" line. Content slides carry \sourcecite{} only when they draw on a different source. Repeated identical citations on every slide add visual noise; this is enforced by the audit checklist's Deck-Level Checks.
• Multi-source (slides draw on different sources): every content slide carries its own \sourcecite{}.

Refer to the Citation Strategy section in ../../style-guides/beamer/style-guide.md for both rendering patterns.

State the decision explicitly to the user before proceeding, for example: "Citation strategy: single-source. Title-slide attribution: Smith. 2024. Paper Title. Publication. Slides with different sources: none." or "Citation strategy: multi-source. Per-slide \sourcecite{} on every content slide."

This is a generation-time decision, not a post-hoc audit catch. Get it right before writing any .tex content. Do not produce per-slide citations on a single-source deck without explicit override slides identified at this step.

Design Requirements

First action: use the Read tool to read these four files now, in order:

1. ../writing-voice-guide/README.md (or equivalent) -- guidance on creating a writing voice layer; slide-specific tone rules (factual titles, no over-narration, no selling the session, takeaway discipline)
2. ../../style-guides/beamer/style-guide.md -- visual design: colors, fonts, templates, macros, chart styling, TikZ patterns, table formatting, slide type patterns, and the complete LaTeX preamble to copy verbatim from its Quick Reference section
3. audit-checklist.md (in this skill's directory) -- the quality audit checklist used in Step 3
4. domain_patterns.md (in this skill's directory) -- structure-specific guidelines for the active entry

Do not write any .tex content before completing all four reads. Do not reconstruct the preamble from memory. The style guide is the single source of truth for visual design. Do not deviate from its color definitions, font settings, or template configurations.

Apply the structure-specific guidelines from the matched domain pattern throughout generation: structural template, rhetoric balance (logos/ethos/pathos), slide count range, density level, Devil's Advocate inclusion, code block inclusion, and transition slide inclusion. Apply the register (Step 0.5) to all slide language: under register=business, translate or gloss the source's domain terms; under register=technical, keep them.

Step 0.7: Outline Checkpoint

This checkpoint is mandatory. Write a brief outline and present it to the user before proceeding. The outline must include:

1. Structure, register, and rhetoric balance: The active structure entry name, the register (business or technical), and the structure's logos/ethos/pathos percentages.

2. Slide sequence with assertion titles: One line per slide showing the slide number, assertion title, and slide type (for example: title, hook, finding, chart, table, diagram, code, Devil's Advocate, transition, takeaway, closing). Follow the structural template from the active domain pattern.

3. Figure plan: For each planned figure, indicate whether it will be:

   • pgfplots (inline in .tex)
   • matplotlib (standalone script, included as PDF)
   • TikZ diagram (inline in .tex)
   • Extracted from source (cropped from source PDF)

   Reference the decision matrix in figure_generation.md to determine which path each figure takes. Default to pgfplots; use matplotlib only when the figure exceeds pgfplots' comfortable range per the matrix.

4. Devil's Advocate slide: Whether included or omitted, and why (per the active domain pattern's rules).

5. Source content inventory: Enumerate every major table and figure cataloged in notes.md (or the source's text extract). For each item, decide one of three handlings and record a one-line reason:

   • Render: produce a slide that includes the magnitudes (numeric values, percentage points, coefficients). The reader sees the source's quantitative content.
   • Compress (high bar; default is Render). Fold into a parent slide as a categorical or summarized treatment, deliberately dropping some magnitudes. Eligible only when another already-Rendered slide carries the same magnitude pattern. Two distinct findings (different magnitudes, different countries, different mechanisms, or different time periods) get two distinct slides; folding them into one is a defect, not an optimization. Reason must be specific (for example, "the magnitude pattern is shown in Figure X already" or "audience does not need per-site detail"). Forbidden patterns: folding findings about different countries with different magnitudes into one card-set slide; folding sector, location, occupation, and other mechanism findings into a single "no single pathway" slide when each has a distinct mechanism; folding a country exception into a parent slide as a footer when the exception itself has a distinct magnitude or mechanism.
   • Drop: omit entirely. Reason must be specific (for example, "robustness check that does not change the main finding" or "appendix-level methodological detail").

   Report a single inventory line such as: "Source content inventory: N tables/figures cataloged. M rendered, K compressed, L dropped." Then list each Compress and Drop decision with its one-line reason. Render decisions do not need individual reasons. The most common information-loss pattern in this skill is silently collapsing two information-dense tables (for example, a "rises" table and a "falls" table, each with per-row magnitudes) into one categorical slide that strips the magnitudes. Make these decisions explicit at outline time, not implicitly during slide writing. If a Compress or Drop reason reads as "for brevity" or "to fit the slide count," reconsider whether the content should be preserved as its own slide.

   Diagnostic signal (not a numerical floor): if the final deck has fewer than 8 slides for an academic paper, working paper, long-form report, or whitepaper, suspect over-compression. The signal is "too few for the source," not "below a numerical floor"; if the source has only three distinct findings, the deck legitimately stays small. Inspect every Compress decision and restore any whose folded items have different magnitudes, countries, mechanisms, or time periods. Audit-time backstop is audit-checklist.md Deck-Level Checks.

6. Citation strategy recap: Restate the decision from Step 0.6 (single-source or multi-source) and which slides, if any, carry overrides. This pins the strategy into the approved outline so it cannot drift during slide writing.

7. Text-column mechanism inventory: for every content slide, declare the mechanism used in its text content. Add these lines to the inventory:

   • Slide K text column: itemize, N parallel claims (default for 3+ parallel claims; use \textbf{\color{DeepTeal}...} or \textbf{\color{SlateNavy}...} lead-ins on the key facts).
   • Slide K text column: prose, N paragraphs (only when content is genuinely narrative: story, scenario walkthrough, single argument with no parallel structure).
   • Slide K text column: TikZ card(s), N siblings (for visual cards using empty-box-plus-overlay; bullet content inside uses minipage+itemize per audit-checklist.md Box Text Anchoring #4).
   • Slide K text column: table, N rows (for structured comparison data).

   This declaration is the planning-time defense against the source-prose-to-slide-prose trap. If the source material (notes.md, summary.md) is written as prose, the slides do not inherit that style. Decompose source prose into discrete claims first, then pick the mechanism. A slide whose declared mechanism is "prose, 3+ paragraphs" with parallel claims is the defect class this step catches: most such slides should be itemize. Write-time enforcement lives in Step 1 (Column Content Invariant), audit-time backstop in audit-checklist.md Content Quality #11.

Save the outline as outline.md in the build directory.

Show the outline to the user and wait for approval before proceeding. If the user requests changes, revise the outline, update outline.md, and re-present. Do not begin writing .tex content or generating figures until the user approves.

Step 0.8: Code-First Figure Generation

Read figure_generation.md (in this skill's directory).

For each figure identified in the approved outline as needing matplotlib:

1. Create the scripts/ directory in the build directory if it does not exist:

   mkdir -p scripts
   

2. Write a standalone Python script to scripts/ following the conventions in figure_generation.md:
   • All imports at the top
   • Palette dict at the top (copy from figure_generation.md)
   • Data defined or loaded at the top
   • Figure construction in the middle
   • plt.savefig() at the bottom, saving to ../figures/<figname>.pdf
   • Standalone: a reader can run it with python3 scripts/<figname>.py and reproduce the figure
3. Create the figures/ directory if it does not exist:

   mkdir -p figures
   

4. Run the script to generate the figure PDF:

   python3 scripts/<figname>.py
   

5. Verify the figure renders correctly by reading the output PDF with the Read tool. Check:
   • Colors match the deck palette
   • Labels are legible at projection size
   • Axes match the slide background (white)
   • No chartjunk (unnecessary gridlines, borders, or axis marks)
   • If the figure has curved arrows with connectionstyle='arc3', the Bezier helper functions from figure_generation.md are used for label placement

If any figure fails verification, fix the script and regenerate.

For figures that stay in pgfplots, proceed as normal (they will be authored inline in the .tex file during the content writing step). The decision matrix from figure_generation.md determines which path each figure takes.

If the approved outline has no matplotlib figures, skip this step entirely. No scripts/ directory is needed.

Content Requirements

The deck must cover the key themes from all parts of the source material. Do not skip or underweight any major section.

Methodology Slide Template

When the deck includes a methodology slide (typically for empirical studies, research papers, or studies with a defined population and method), use this template. The slide is one frame, structured into seven ordered elements; drop any element that is not load-bearing for the source.

The seven elements (left column = study setup, right column = evaluation):

Layout: two equal columns. Left column holds the elements present from {Question, Method, Data, Population} (study setup). Right column holds the elements present from {Outcomes, Comparison, Analysis} (evaluation). Order moves question to measurement to analysis: left top to left bottom, then right top to right bottom.

Visual treatment: each element is one short phrase, not a paragraph or bullet list. Label each phrase with the element name as a bold colored lead: \textbf{\color{DeepTeal}Question:} then the phrase. All seven labels use DeepTeal; do not vary color across labels. The bold-colored label is the visual anchor; the phrase carries the content.

Drop what is not load-bearing. The template is a checklist of what could be on the slide, not what must be. Examples:

• A behavioral RCT often drops Method (the design is the method) and emphasizes Population and Comparison.
• A methods paper often drops Population and emphasizes Comparison and Analysis.
• A descriptive empirical paper often drops Comparison (there is no counterfactual).
• A non-empirical source (opinion piece, position paper, blog) drops the whole slide.

Column balance after drops. If dropping elements leaves one column with fewer than 2 elements, rebalance: move Outcomes to the left column, or collapse to a single-column layout. Do not ship a methodology slide with one column at near-capacity and the other near-empty.

Sanity check. A reader who finishes the slide should be able to predict the shape of the findings slides that follow. If they can't, an element is missing: restore one of the dropped elements, or rewrite an existing phrase to carry more weight.

Limitations Slide Template

When the source material has an Issues section with substantive limitations, include a "Limitations and Critique" slide near the end of the deck (in Act III, before the closing). Present 2-3 of the strongest objections, each rendered in the three-part Devil's Advocate format below.

Three-part format for each item:

• Concern: what a skeptic would say (the objection in its strongest form).
• Why reasonable: why the concern is legitimate (steel-man the skeptic; do not dismiss).
• Response: how the source addresses the concern, or how the limitation is acknowledged when it cannot be fully resolved.

Each item gets its own card or block. Visual treatment: 2-3 colored cards side-by-side or stacked, with bolded section labels (e.g., \textbf{\color{DeepTeal}Concern:}, \textbf{\color{SlateNavy}Why reasonable:}, \textbf{\color{DeepTeal}Response:}). Loose prose paragraphs without the three-part labels are a defect: the three-part format reads as a Devil's Advocate exchange, which is the pedagogical pattern this slide is designed for; loose prose loses that affordance.

Structure modifiers. The active domain pattern determines whether this slide is required, optional, or omitted:

• MBA / Executive (default): Include when the source has substantive limitations; an academic source almost always does.
• Teaching Lecture: Include when the source has an Issues section.
• Faculty Development: Include (faculty audiences are skeptical by nature).
• Professional Audience: Optional (depends on whether the talk makes a claim or reports findings).
• Consulting Workshop: Built into the exercise debrief framing; do not add a standalone slide.
• Working Deck: Not needed.

Visual Mechanism Selection

Before writing any slide content, classify each planned slide's content and select the appropriate LaTeX mechanism. Do not default to TikZ for everything. The goal is beautiful, graphical slides, and the right mechanism for the content type produces better visuals than forcing everything into freeform TikZ placement.

Decision rule

Every TikZ diagram must contain at least one element that cannot be represented as a list item or table cell: an arrow showing causation, a spatial position conveying meaning, a data-driven axis, or a geometric relationship between elements. If the slide content is a list of items rendered as labeled boxes without meaningful spatial relationships between them, use a table or formatted list instead.

Mechanism by content type

What "graphical" means for non-TikZ mechanisms

Tables and formatted lists are visual representations when properly styled:

• A booktabs table with alternating PaleBlue row shading, colored header cells, and icon-like symbols ($\to$, $\checkmark$, $\times$) is graphical.
• An enumerate list with DeepTeal numbered items, SlateNavy bold lead text, and generous \itemsep spacing is graphical.
• A two-column layout with a styled text block and a chart is graphical.

"Graphical" means the slide communicates visually,

…(truncated)