Menu
Create or edit a Beamer slide deck. Use when the user asks to build, write, or edit a presentation or slide deck.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | deck |
| origin | adapted from https://github.com/scunning1975/MixtapeTools |
| targets | ["claude","opencode","antigravity"] |
| description | Create or edit a Beamer slide deck. Use when the user asks to build, write, or edit a presentation or slide deck. |
Build or edit a Beamer presentation following the Rhetoric of Decks principles.
Open and read the rhetoric.md file co-located with this skill (same folder as this SKILL.md) before doing anything else. It contains the rhetoric principles, slide architecture standards, and LaTeX style template that govern all decks. Use it as your benchmark throughout.
Answer these three questions before touching any file:
Q1: New deck or editing existing?
.tex file(s) first. Understand the existing palette, structure, and style before changing anything.Q2: Who is the audience?
| Audience | Implications |
|---|---|
| Academic seminar | Maximum sparsity. One idea per slide, no exceptions. Titles carry the full argument. Appendix heavy. |
| Teaching lecture | Clarity over compression. Repetition is welcome. Progressive revelation — build up formally step by step. Check prerequisite chain. |
| Co-authors / working deck | More detail is acceptable. Document choices explicitly. Preserve uncertainty where it exists. |
| External / non-academic | Storytelling and visual impact over technical precision. Minimal jargon. Lead with the human stakes. |
If unclear, ask the user before proceeding.
Q3: What is the tone?
rhetoric.mdNew decks get a descriptive, lowercase filename — no spaces, no generic names like deck.tex or slides.tex.
Format: topic_audience.tex
| Example | Why it works |
|---|---|
did_estimation_seminar.tex | Topic + audience in the name |
macro_intro_lecture_03.tex | Course lecture with sequence number |
chapter1_coauthor.tex | Working deck tied to a paper chapter |
labor_supply_defense.tex | Defense/job talk clearly marked |
If the project only has one deck, a short topic name is enough (parental_jobloss.tex). Add the audience suffix when there are multiple decks or when the audience materially changes the content.
The compile loop and open command use whatever filename is chosen — never hardcode deck.tex.
Follow the rhetoric principles in rhetoric.md throughout. Key constraints that are non-negotiable:
rhetoric.md)After every edit, run:
pdflatex -interaction=nonstopmode <filename>.tex 2>&1 | grep "Overfull" | grep -v "hyperref\|beamer"
Then check fatal errors:
grep "^!" <filename>.log
Fix all fatal errors before anything else.
For overflow warnings, apply the thresholds from rhetoric.md. Zero fatal errors required before distributing.
If the deck uses TikZ: before finalising, run the /tikz skill on each figure — it performs the label-collision, whitespace, and edge-clipping checks; don't re-derive them inline here.
When the deck needs data visualisations:
generate_figures.R) using ggplot2, or a Python script using matplotlibrhetoric.md: white background, series separated by the Seeblau tint ladder (not multiple hues), textures only beyond four series; Hamburg red reserved for semantic emphasisfigures/ subdirectoryopen <filename>.pdf
Read all titles in sequence. Do they tell the argument? If not, fix the titles before anything else.
Peripheral vision audit for empirical output. Finds what the author cannot see — problems hiding in plain sight (vices) and opportunities being overlooked (virtues). Inspired by Viktor Shklovsky's defamiliarization and conversations with Jason Fletcher. Use when output exists and interpretation is about to happen.
Convene a multi-model "council" to answer a hard question — four different model families answer in parallel, anonymously peer-rank each other, and a Claude Opus chairman synthesizes the final answer. Adaptation of karpathy/llm-council for local CLIs (agy, codex, vibe) plus Claude subagents. Can judge attached material: point it at project files (R scripts, .tex/.md drafts, data dictionaries) or paste content inline, and every member sees it (PDFs are extracted to text by a subagent first). Use when the user wants cross-model consensus, a second/third opinion, or maximum-confidence judgment on open-ended, high-stakes, or contested questions — invoke on "/council", "ask the council", "convene the council", "council on …". Not for quick factual lookups (the fan-out costs ~9 model calls).
Expert economics paper writing assistant synthesizing advice from 50+ top guides by Cochrane, McCloskey, Shapiro, Head, Bellemare, Goldin, Glaeser, Kremer, and other leading economists. USE THIS SKILL whenever the user writes, edits, reviews, rewrites, or structures any economics paper, thesis, job market paper, abstract, introduction, conclusion, results section, literature review, or referee response. Also handles LaTeX formatting, presentations, and paper audits. Covers all paper types (applied, theory, structural, mixed) and all sections. Do NOT invoke for tasks that are purely code, data manipulation, or tool configuration with no prose-writing component.
Decision premortem — imagine the plan has already failed, then work backward to find out why. Use before committing to high-stakes, still-reversible decisions (job market strategy, dissertation chapter direction, research design, grant framing). Generates failure scenarios and investigates the most significant ones in depth (parallel subagents in Claude Code; sequential inline in OpenCode/Antigravity), then synthesizes the three most critical risks with concrete revisions.
Systematic audit and cross-language replication of empirical research projects. Performs five audits (code, cross-language replication, directory structure, output automation, econometrics) and files a formal referee report with a Beamer deck.
Structure a response to referee or reviewer comments interactively, one comment at a time. Classifies each point, drafts responses, and waits for user approval before proceeding. Use when responding to referee2 reports, journal referee reports, or co-author feedback. Do not auto-invoke (e.g. at the end of a referee2 run) — always wait for the user to explicitly ask.