Mmcp.market

create-lecture skill

by pedrohcgs·pedrohcgs/claude-code-my-workflow·1.6k stars·MIT

Create a new Beamer lecture `.tex` from source papers and materials, with notation consistency checks and the project's preamble wired in. Use when user says "create a lecture on X", "new lecture from these papers", "start a deck on topic Y", "scaffold a new Beamer file", "build me a lecture from these PDFs". Scaffolds the full deck — NOT for compiling existing `.tex` (use `/compile-latex`).

A100/100content scan

Is the create-lecture skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.

No findings.

Install the create-lecture skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/pedrohcgs/claude-code-my-workflow.git /tmp/claude-code-my-workflow
mkdir -p ~/.claude/skills
cp -r /tmp/claude-code-my-workflow/.claude/skills/create-lecture ~/.claude/skills/create-lecture
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

Lecture Creation Workflow

Create a beautiful, pedagogically excellent Beamer lecture deck.

This is a collaborative, iterative process. The instructor drives the vision; Claude is a thinking partner.

CONSTRAINTS (Non-Negotiable)

  1. Read the knowledge base FIRST — notation registry, narrative arc, applications database
  2. Every new symbol MUST be checked against the notation registry
  3. Motivation before formalism — no exceptions
  4. Worked example within 2 slides of every definition
  5. Max 2 colored boxes per slide
  6. No \pause or overlay commands (check project rules)
  7. Transition slides at major conceptual pivots
  8. Thread at least 1 running empirical application throughout
  9. All citations verified against the bibliography
  10. Work in batches of 5-10 slides — share for feedback, don't bulk-dump

WORKFLOW

Phase 0: Intake & Context (Pre-Flight Report required)

Read the inputs, then produce a Pre-Flight Report in your response before Phase 1 starts.

Inputs to read:

  • .claude/rules/knowledge-base-template.md — notation registry, narrative arc, applications
  • .claude/rules/content-invariants.md — INV-1..INV-8 govern slide content
  • Any source papers / existing slides the user provided
  • The previous lecture's .tex (last section + ending slide) if one exists

Required Pre-Flight Report block:

## Pre-Flight Report

**Sources read:**
- [source 1]: [one-line takeaway — what notation, what result, what diagram]
- [source 2]: ...

**Notation registry check:**
- New symbols this lecture will introduce: [list]
- Symbols reused from prior lectures: [list, with the lecture each was introduced in]
- Conflicts detected: [none / specific clashes]

**Narrative position:** [Where does this lecture sit in the course arc? What did the previous lecture end on? What does the next lecture need you to set up?]

**Pedagogical goal:** [one sentence]

**Running application:** [which real-world example threads through this deck]

State the pedagogical goal, get user confirmation, then proceed.

First-lecture fallback (fresh fork, empty knowledge base). If .claude/rules/knowledge-base-template.md still has unfilled placeholder tables (no notation registry entries, no applications, no prior lectures in Slides/), do NOT halt waiting for it. Instead:

  1. Acknowledge the template is empty and we're creating the course's first lecture.
  2. Propose a minimal starter knowledge base from the user's topic: 5-8 key symbols with conventions, 1-2 running applications, a short narrative arc (intro → main idea → implications). Present for approval.
  3. Write the approved stub into the knowledge base template so subsequent lectures inherit it.
  4. Continue to Phase 1.

This prevents /create-lecture from deadlocking for every new forker.

Phase 1: Paper Analysis (When Papers Provided)

  • Split into chunks, extract key ideas
  • Map paper notation → course notation
  • Identify slide-worthy content
  • Present summary for approval

Phase 2: Structure Proposal

  • Propose outline (5-Act or 3-Part template)
  • List TikZ diagrams and R figures needed
  • List new notation to introduce
  • GATE: User approves before Phase 3

Phase 3: Draft Slides (Iterative)

  • Work in batches of 5-10 slides
  • Check notation, apply creation patterns
  • Quality checks during drafting

Phase 4: Figures & Code

  • R scripts following conventions
  • TikZ diagrams in Beamer source (single source of truth)
  • Save RDS for future Quarto integration

Phase 5: Polish & Compile

  • Full 3-pass compilation
  • Run Devil's Advocate
  • Run Substance Review (if domain reviewer configured)
  • Update knowledge base with new notation

Post-Creation Checklist

[ ] Lecture compiles without errors
[ ] No overfull hbox > 10pt
[ ] All citations resolve
[ ] Every definition has motivation + worked example
[ ] Max 2 colored boxes per slide
[ ] 2-3 Socratic questions embedded
[ ] Transition slides between sections
[ ] At least 1 running application threaded throughout
[ ] New notation added to knowledge base
[ ] Session log updated
[ ] Devil's Advocate run

Cross-references

  • .claude/skills/translate-to-quarto/SKILL.md — port the finished Beamer deck to a Quarto RevealJS mirror.
  • .claude/skills/qa-quarto/SKILL.md — adversarial Beamer↔Quarto parity (loop-until-dry).
  • .claude/skills/deploy/SKILL.md — render + publish the lecture to GitHub Pages.
  • .claude/skills/scaffold-exercises/SKILL.md — problem sets + solutions to accompany the lecture.

More skills from pedrohcgs/claude-code-my-workflow

  • Aadjudicate-reviewTurn an incoming set of findings — from an AI reviewer, a referee report, a code review, a linter, or a second model — into verified fixes, without letting a confident misread damage correct work. Every finding is a CANDIDATE until checked against the actual source. Use whenever you receive review comments, audit findings, or a critique you did not write yourself, especially when the reviewer is a model or when the volume is too large to check by feel.
  • Aaudit-reproducibilityEnforce the replication-protocol.md rule by cross-checking numeric claims in a manuscript against the actual R / Stata / Python outputs. Report PASS/FAIL per claim against tolerance thresholds. Use before submission and before releasing a replication package.
  • Ablast-radiusBefore and after changing anything shared — a function's return value, a signature, a schema, a label set, a config default, a constant, a file format — find every consumer and actually run them. Catches the change that looks purely additive but silently breaks a contract in a file you never opened. Use when editing shared code, adding a field/column/return element, renaming, changing units or defaults, or touching a pipeline that produces reported numbers.
  • Acapture-environmentSnapshot the computational environment for a replication package — detects the analysis stack (R / Stata / Python) and emits the right lockfiles (renv.lock + sessionInfo.txt, requirements.txt / environment.yml / uv.lock, Stata version + ado package list), records seeds and RNG kind, optionally writes a pinning Dockerfile, and produces a paste-ready "Computational requirements" block. Use when user says "capture the environment", "snapshot my dependencies", "pin the versions", "make a renv.lock / requirements.txt", "make this byte-reproducible", or before releasing a replication package to openICPSR / the AEA Data Editor.
  • AchallengeStress-test a finding against the choices you did not make. Enumerates the discrete forks a competent analyst could have taken (measure definition, sample filter, control set, clustering level, weighting, functional form), runs the specification grid, and reports the distribution rather than a point estimate — then attacks the identifying assumption with named, computable sensitivity statistics. Use when the user says "is this robust", "challenge this result", "specification curve", "multiverse", "how sensitive is this", "what if I'd used a different measure", "stress-test my estimate", or before a result becomes a headline claim. NOT a reviewer of prose or code — it challenges the CLAIM.
  • AcheckpointSave a structured state snapshot before stopping or handing off. Captures the active plan, recent decisions, file pointers (with line numbers), open questions, and the next 1–3 actions into a checkpoint file under `quality_reports/checkpoints/`. Optionally proposes `[LEARN]` entries to add to MEMORY.md. Use when user says "checkpoint", "save state", "snapshot before I stop", "where am I", "wrap up the session for handoff", or before a long break / model switch / collaborator handoff. Companion to (NOT replacement for) the narrative session-log workflow.
  • Acoauthor-briefGenerate a co-author / collaborator handoff brief for a multi-author, multi-machine project — summarizing what changed since the last brief (git delta), the current state of each artifact (manuscript, analysis, slides), open questions, how to reproduce locally, and any restricted-data access steps. Use when user says "coauthor brief", "handoff brief", "bring my coauthor up to speed", "what changed since last week", "onboard a collaborator", "write a handoff for [name]", or before sending a co-author the repo. NOT a commit or a checkpoint — it is the cross-machine, cross-person summary `meta-governance.md` only partially covers.
  • AcommitCommit the current work — runs the quality, consistency and passport gates, branches off main if needed, stages specific files, and writes a commit whose subject states what is now true. Pushes and opens a pull request only with --pr or when the user asks; never merges — a merge happens only when the user explicitly says to merge. Use ONLY on explicit commit intent — user says "commit", "let's commit this", "open a PR", or prefixes with `/commit`. Do NOT auto-invoke on vague end-of-task phrases ("we're done", "wrap up") — those require explicit confirmation first. Never force-pushes or skips hooks.
  • Acompile-latexCompile a Beamer LaTeX slide deck with XeLaTeX (3 passes + bibtex). Use when user says "compile", "build the slides", "rebuild the PDF", "run latex", "render the tex", or asks why a `.tex` file isn't producing a PDF. Operates on `Slides/*.tex`.
  • Acompress-sessionDistill the current conversation into a structured note (decisions made, open questions, file pointers with line numbers, next 1–3 actions) and save to `quality_reports/session_logs/` before auto-compression. Differs from `/checkpoint` (explicit stop-point snapshot) and from auto-compaction (which truncates rather than distills). Use when context is approaching auto-compact threshold, when a long pipeline has accumulated many decisions, or when the user says "compress", "distil this session", "before we hit auto-compact", "structured handoff before context resets".
  • Acontext-statusShow current context status and session health. Use to check how much context has been used, whether auto-compact is approaching, and what state will be preserved.
  • Acredible-claimsResearch-brief + claim-record discipline for delegated or AI-assisted research work. Use when starting any substantive research task or long autonomous run (write the brief first), and when reporting results that will support a claim in a paper or decision (produce the claim record). Keeps faster execution from being confused with credible evidence.

All agent skills → · MCP servers