My Claude Code Setup

A Comprehensive Guide to Multi-Agent Slide Development, Code Review, and Research Automation

Author

Pedro H. C. Sant’Anna

Published

February 6, 2026

1 Why This Workflow Exists

1.1 The Problem

If you’ve ever built lecture slides, you know the pain:

  • Context loss between sessions. You pick up where you left off, but Claude doesn’t remember why you chose that notation, what the instructor approved, or which bugs were fixed last time.
  • Quality is inconsistent. One slide has perfect spacing; the next overflows. Citations compile in Overleaf but break locally. Figures look great on your screen but pixelated on a projector.
  • Review is manual and exhausting. You proofread 140 slides by hand. You miss a typo in an equation. A student catches it during lecture.
  • No one checks the math. Grammar checkers catch “teh” but not a flipped sign in a decomposition theorem.

This workflow solves all of these problems. You describe what you want — “translate Lecture 5 to Quarto” or “create a new lecture on synthetic control” — and Claude handles the rest: plans the approach, implements it, runs specialized reviewers, fixes issues, verifies quality, and presents results. Like a contractor who manages the entire job.

1.2 What Makes Claude Code Different

Claude Code is a CLI tool that runs on your computer with full access to your file system, terminal, and git. Here is what that enables:

Capability What It Means for You
Read & edit your files Surgical edits to .tex, .qmd, .R files in place
Run shell commands Compile LaTeX, run R scripts, render Quarto — directly
Access git history Commits, PRs, branches — all from the conversation
Persistent memory CLAUDE.md + MEMORY.md survive across sessions
Orchestrator mode Claude autonomously plans, implements, reviews, fixes, and verifies
Multi-agent workflows 10 specialized agents for proofreading, layout, pedagogy, code review
Quality gates Automated scoring — nothing ships below 80/100
TipCase Study: Econ 730 at Emory

This workflow was developed over 6+ sessions building a PhD course on Causal Panel Data. The result: 6 complete lectures (140+ slides each), with Beamer + Quarto versions, interactive Plotly charts, TikZ diagrams, and R replication scripts — all managed by the orchestrator and reviewed by 10 specialized agents across 5 quality dimensions.

2 The System in Action

Before diving into configuration details, here is what the system actually does. This section shows the three core mechanisms that make the workflow powerful: specialized agents, adversarial QA, and automatic quality scoring.

2.1 Why Specialized Agents Beat One-Size-Fits-All

Consider proofreading a 140-slide lecture deck. You could ask Claude:

“Review these slides for grammar, layout, math correctness, code quality, and pedagogical flow.”

Claude will skim everything and catch some issues. But it will miss:

  • The equation on slide 42 where a subscript changed from \(m_t^{d=0}\) to \(m_t^0\)
  • The TikZ diagram where two labels overlap at presentation resolution
  • The R script that uses k=10 covariates but the slide says k=5

Now compare with specialized agents:

Agent Focus What It Catches
proofreader Grammar only “principle” vs “principal”
slide-auditor Layout only Text overflow on slide 37
pedagogy-reviewer Flow only Missing framing sentence before Theorem 3.1
r-reviewer Code only Missing set.seed()
domain-reviewer Substance Slide says 10,000 MC reps, code runs 1,000

Each agent reads the same file but examines a different dimension with full attention. The /slide-excellence skill runs them all in parallel.

2.2 The Adversarial Pattern: Critic + Fixer

The single most powerful pattern in this system is the adversarial QA loop:

+------------------+
|  quarto-critic   |  "I found 12 issues. 3 Critical."
|  (READ-ONLY)     |
+--------+---------+
         |
    +----v----+
    | Verdict |
    +----+----+
     /       \
APPROVED   NEEDS WORK
    |          |
  Done    +----v---------+
          | quarto-fixer |  "Fixed 12/12 issues."
          | (READ-WRITE) |
          +----+---------+
               |
          +----v----------+
          | quarto-critic |  "Re-audit: 2 remaining."
          | (Round 2)     |
          +----+----------+
               |
          ... (up to 5 rounds)

Why it works: The critic can’t fix files (read-only), so it has no incentive to downplay issues. The fixer can’t approve itself (the critic re-audits). This prevents the common failure of Claude saying “looks good” about its own work.

TipReal Example

In Econ 730 Lecture 6, the critic caught that the Quarto version used \cdots (a placeholder) where the Beamer version had the full Hajek weight formula. The fixer replaced it. On re-audit, the critic found 8 more instances of missing (X) arguments on outcome models. After 4 rounds, the Quarto slides matched the Beamer source exactly.

2.3 The Orchestrator: Coordinating Agents Automatically

Individual agents are specialists. Skills like /slide-excellence and /qa-quarto coordinate a few agents for specific tasks. But in day-to-day work, you should not have to think about which agents to run. That is the orchestrator’s job.

The orchestrator protocol (.claude/rules/orchestrator-protocol.md) is an auto-loaded rule that activates after any plan is approved. It implements the plan, runs the verifier, selects review agents based on file types, applies fixes, re-verifies, and scores against quality gates. It loops until the score meets threshold or max rounds are exhausted.

You never invoke the orchestrator manually — it is the default mode of operation for any non-trivial task. Skills remain available for standalone use (e.g., /proofread for a quick grammar check), but the orchestrator handles the full lifecycle automatically. See Pattern 2 for the complete workflow.

2.4 Quality Scoring: The 80/90/95 System

Every file gets a quality score from 0 to 100:

Score Threshold Meaning Action
80+ Commit Safe to save progress git commit allowed
90+ PR Ready for deployment gh pr create encouraged
95+ Excellence Exceptional quality Aspirational target
< 80 Blocked Critical issues exist Must fix before committing

2.4.1 How Scores Are Calculated

Points are deducted for issues:

Issue Deduction Why Critical
Equation overflow -20 Math cut off = unusable
Broken citation -15 Academic integrity
Equation typo -10 Teaches wrong content
Text overflow -5 Content cut off
Label overlap -5 Diagram illegible
Notation inconsistency -3 Student confusion

2.4.2 The Stop Hook: Mandatory Verification

The .claude/settings.json includes a Stop hook that runs at the end of every task:

“Did Claude verify its output? If the task modified .tex, .qmd, .R, or .svg files and verification was NOT performed, block completion.”

This means Claude cannot say “done” without actually compiling, rendering, or otherwise verifying the output.

WarningDon’t Disable the Stop Hook

It’s tempting to remove the hook for speed. Don’t. In Econ 730, the hook caught unverified TikZ diagrams that would have deployed with overlapping labels, broken SVGs in Quarto slides that wouldn’t display, and R scripts with missing intercept terms that produced silently wrong estimates.

2.5 Creating Your Own Domain Reviewer

The template includes domain-reviewer.md — a skeleton for building a substance reviewer specific to your field.

2.5.1 The 5-Lens Framework

Every domain can benefit from these five review lenses:

Lens What It Checks Example (Economics) Example (Physics)
Assumption Audit Are stated assumptions sufficient? Is overlap required for ATT? Is the adiabatic approximation valid here?
Derivation Check Does the math check out? Do decomposition terms sum? Do the units balance?
Citation Fidelity Do slides match cited papers? Is the theorem from the right paper? Is the experimental setup correctly described?
Code-Theory Alignment Does code implement the formula? R script matches the slide equation? Simulation parameters match theory?
Logic Chain Does the reasoning flow? Can a PhD student follow backwards? Are prerequisites established?

To customize, open .claude/agents/domain-reviewer.md and fill in:

  1. Your domain’s common assumption types
  2. Typical derivation patterns to verify
  3. Key papers and their correct attributions
  4. Code-theory alignment checks for your tools
  5. Logic chain requirements for your audience

3 Setting Up Your Project

3.1 Step 1: Fork the Template

# Clone the template
git clone https://github.com/pedrohcgs/claude-code-my-workflow.git my-project
cd my-project

# Remove template git history and start fresh
rm -rf .git
git init
git add -A
git commit -m "Initial project from claude-code-academic-workflow template"

3.2 Step 2: Customize CLAUDE.md

Open CLAUDE.md and replace all [BRACKETED PLACEHOLDERS]:

  1. Project name and institution
  2. Folder structure (adjust to your layout)
  3. Current project state (your lectures/papers)
  4. Beamer environments (your custom LaTeX environments)
  5. CSS classes (your Quarto theme classes)

3.3 Step 3: Create Your Knowledge Base

Open .claude/rules/knowledge-base-template.md and fill in:

  1. Notation registry — every symbol you use, where it’s introduced, and anti-patterns
  2. Applications database — datasets, papers, and R packages you reference
  3. Design principles — what you’ve approved and what you’ve overridden
TipStart Small

You don’t need to fill everything in upfront. Start with 5-10 notation entries and add more as you develop lectures. The template shows the format — just follow the pattern.

3.4 Step 4: Configure Permissions

Review .claude/settings.json. The template includes permissions for:

  • Git operations (status, commit, push, PR)
  • LaTeX compilation (xelatex, bibtex, latexmk)
  • Quarto rendering
  • R script execution
  • Utility scripts

Add any additional tools you use (e.g., python3, julia, pandoc).

3.5 Step 5: Test It

# Test 1: Can Claude compile LaTeX?
# In Claude Code, type:
/compile-latex MyFirstLecture

# Test 2: Can Claude proofread?
/proofread Slides/MyFirstLecture.tex

# Test 3: Does the quality score work?
python scripts/quality_score.py Quarto/MyFile.qmd

4 The Building Blocks

Now that you have seen what the system does, here is how it is configured. Claude Code’s power comes from five configuration layers that work together. Think of them as the operating system for your academic project.

4.1 CLAUDE.md — Your Project’s Brain

CLAUDE.md is the single most important file. Claude reads it at the start of every session. It contains:

  • Project overview — what you’re building and why
  • Folder structure — where everything lives
  • Available tools — what slash commands and agents exist
  • Design principles — visual, pedagogical, and technical standards
  • Current state — which lectures are done, what’s in progress
  • Workflow rules — how to compile, deploy, commit
# CLAUDE.MD --- My Course Development

**Project:** Econ 730 --- Causal Panel Data
**Institution:** Emory University

## Quick Reference
| Command | What It Does |
|---------|-------------|
| `/compile-latex [file]` | 3-pass XeLaTeX compilation |
| `/proofread [file]` | Grammar/typo review |
| `/deploy [Lecture]` | Render and deploy to GitHub Pages |
ImportantKey Principle

CLAUDE.md is Claude’s persistent memory. If it’s not in CLAUDE.md, Claude will forget it next session. Every design decision, naming convention, and workflow rule should be documented here.

4.2 Rules — Domain Knowledge That Auto-Loads

Rules are markdown files in .claude/rules/ that Claude loads automatically based on context. They encode your project’s standards:

.claude/rules/
+-- verification-protocol.md    # "Always verify output before reporting done"
+-- quality-gates.md            # "Score must be 80+ to commit"
+-- orchestrator-protocol.md    # "After plan approval, run the full loop"
+-- r-code-conventions.md       # "Always use set.seed(), never hardcode paths"
+-- tikz-visual-quality.md      # "No label overlaps, consistent colors"
+-- beamer-quarto-sync.md       # "Every Beamer edit must sync to Quarto"
+-- knowledge-base-template.md  # Your domain notation and conventions

Why rules matter: Without them, Claude will use generic defaults. With them, Claude follows your standards consistently across sessions.

4.2.1 Example: R Code Conventions Rule

# R Code Conventions

## Script Structure
Every R script MUST have:
1. Header block (title, author, date, description)
2. Package loading (grouped by purpose)
3. Single `set.seed(YYYYMMDD)` for reproducibility
4. Named sections with `# ---- Section Name ----`

## Console Output
- NO decorative banners or progress bars
- Use `message()` for milestones only
- Save results to RDS, not print to console

4.3 Skills — Reusable Slash Commands

Skills are multi-step workflows invoked with /command. Each skill lives in .claude/skills/[name]/SKILL.md:

---
name: compile-latex
description: Compile LaTeX with 3-pass XeLaTeX + bibtex
disable-model-invocation: true
argument-hint: "[filename without .tex extension]"
---

# Steps:
1. cd to Slides/
2. Run xelatex pass 1
3. Run bibtex
4. Run xelatex pass 2
5. Run xelatex pass 3
6. Check for errors
7. Report results

Skills you get in the template:

Skill Purpose When to Use
/compile-latex Build PDF from .tex After any Beamer edit
/deploy Render Quarto + sync to docs/ Before pushing to GitHub Pages
/proofread Grammar and consistency check Before every commit
/qa-quarto Adversarial Quarto QA After translating Beamer to Quarto
/slide-excellence Full multi-agent review Before major milestones
/create-lecture New lecture from scratch Starting a new topic

4.4 Agents — Specialized Reviewers

Agents are the real power of this system. Each agent is an expert in one dimension of quality:

.claude/agents/
+-- proofreader.md        # Grammar, typos, consistency
+-- slide-auditor.md      # Visual layout, overflow, spacing
+-- pedagogy-reviewer.md  # Narrative arc, notation clarity, pacing
+-- r-reviewer.md         # R code quality and reproducibility
+-- tikz-reviewer.md      # TikZ diagram visual quality
+-- quarto-critic.md      # Adversarial Quarto vs Beamer comparison
+-- quarto-fixer.md       # Applies critic's fixes
+-- beamer-translator.md  # Beamer -> Quarto translation
+-- verifier.md           # Task completion verification
+-- domain-reviewer.md    # YOUR domain-specific substance review

4.4.1 Agent Anatomy

Each agent file has YAML frontmatter + detailed instructions:

---
name: proofreader
description: Reviews slides for grammar, typos, and consistency
---

# Proofreader Agent

## Role
You are an expert academic proofreader reviewing lecture slides.

## What to Check
1. Grammar and spelling errors
2. Inconsistent notation
3. Missing or broken citations
4. Content overflow (text exceeding slide bounds)

## Report Format
Save findings to: quality_reports/[FILENAME]_report.md

## Severity Levels
- **Critical:** Math errors, broken citations
- **Major:** Grammar errors, overflow
- **Minor:** Style inconsistencies
NoteWhy Specialized Agents?

A single Claude prompt trying to check grammar, layout, math, and code simultaneously will do a mediocre job at all of them. Specialized agents focus on one dimension and do it thoroughly. The /slide-excellence skill runs them all in parallel, then synthesizes results.

4.5 Settings — Permissions and Hooks

.claude/settings.json controls what Claude is allowed to do:

{
  "permissions": {
    "allow": [
      "Bash(git status *)",
      "Bash(xelatex *)",
      "Bash(Rscript *)",
      "Bash(quarto render *)",
      "Bash(./scripts/sync_to_docs.sh *)"
    ]
  },
  "hooks": {
    "Stop": [
      {
        "hooks": [{
          "type": "prompt",
          "prompt": "Check if Claude verified its work..."
        }]
      }
    ]
  }
}

The Stop hook is crucial — it runs at the end of every task and blocks completion if Claude didn’t verify its output. This prevents the common failure mode of “it compiled but I didn’t check if it looks right.”

4.6 Memory — Cross-Session Persistence

Claude Code has an auto-memory system at ~/.claude/projects/[project]/memory/MEMORY.md. This file persists across sessions and is loaded into every conversation.

Use it for: - Key project facts that never change - Corrections you don’t want repeated ([LEARN:tag] format) - Current plan status

# Auto Memory

## Key Facts
- Project uses XeLaTeX, not pdflatex
- Bibliography file: Bibliography_base.bib

## Corrections Log
- [LEARN:r-code] Package X drops obs silently when covariate is missing
- [LEARN:citation] Post-LASSO is Belloni (2013), NOT Belloni (2014)
- [LEARN:workflow] Every Beamer edit must auto-sync to Quarto

4.6.1 Plans — Compression-Resistant Task Memory

While MEMORY.md stores long-lived project facts, plans store task-specific strategy. Every non-trivial plan is saved to quality_reports/plans/ with a timestamp. This means:

  • Plans survive auto-compression (they are on disk, not just in context)
  • Plans survive session boundaries (readable in any future session)
  • Plans create an audit trail of design decisions

See Pattern 1 in Workflow Patterns for the full protocol.

4.6.2 Session Logs — Why-Not-Just-What History

Git commits record what changed, but not why. Session logs fill this gap. Claude writes to quality_reports/session_logs/ at three points: right after plan approval, incrementally during implementation (as decisions happen), and at session end. This means the log captures reasoning as it happens, before auto-compression can discard it.

New sessions can read these logs to understand not just the current state of the project, but the reasoning behind it. See Pattern 1 in Workflow Patterns for the full protocol.

5 Workflow Patterns

The first two patterns are meta-patterns — they govern how every task flows. Learn these first, then the specific workflows make more sense.

5.1 Pattern 1: Plan-First Development

The plan-first pattern ensures that non-trivial tasks begin with thinking, not typing.

5.1.1 Why Planning Matters

The most common failure mode in AI-assisted development is not bad code — it is solving the wrong problem, or solving the right problem in a fragile order. Plan-first development forces an explicit design step before any file is touched.

Without a plan:

  • Claude starts editing immediately, discovers a dependency on slide 3 that changes the approach, and has to undo work
  • Context compression discards the reasoning behind a design choice, and Claude makes a contradictory decision later
  • The user and Claude have different mental models of what “done” looks like

With a plan:

  • The approach is agreed upon before any edits happen
  • The plan is saved to disk, so it survives compression and session boundaries
  • Implementation has a checklist to follow, reducing drift

5.1.2 The Protocol

Non-trivial task arrives
  |
  +-- Step 1: Enter Plan Mode (EnterPlanMode)
  +-- Step 2: Draft plan (approach, files, verification)
  +-- Step 3: Save to quality_reports/plans/YYYY-MM-DD_description.md
  +-- Step 4: Present plan to user
  +-- Step 5: User approves (or revises)
  +-- Step 6: Save initial session log (capture context while fresh)
  +-- Step 7: Orchestrator takes over (see Pattern 2)
  +-- Step 8: Update session log + plan status to COMPLETED

5.1.3 Context Preservation: Never /clear

An important companion to plan-first development is context preservation. Claude Code has two ways to free context space:

  • /clear — destroys everything. All context, corrections, and reasoning are gone. Starting over from zero.
  • Auto-compression — Claude Code automatically compresses the conversation when it gets long. It keeps the most important context and discards redundant detail. This is graceful degradation.

The rule is simple: never use /clear. Let auto-compression do its job. And as a safety net, always save plans and important decisions to files on disk, where they cannot be compressed away.

TipRecovery After Compression

If you notice Claude has lost context after auto-compression, point it to the saved plan file:

“Read quality_reports/plans/2026-02-06_translate-lecture5.md — that’s our current plan.”

Because the plan is on disk, recovery is instant.

Combined with the [LEARN] tag system from Pattern 7, plans and context preservation form a complete memory layer: plans save task strategy, [LEARN] tags save corrections, and auto-compression keeps the conversation manageable without losing what matters.

5.1.4 Session Logging

Session logs (quality_reports/session_logs/YYYY-MM-DD_description.md) are a running record of why things happened. They have three distinct behaviors, each solving a different problem:

After plan approval — create the log with the goal, plan summary, and rationale for the chosen approach (including rejected alternatives). This captures decisions while context is richest. If you wait, auto-compression may discard the reasoning.

During implementation — append to the log as you work. Every time a design decision is made, a problem is discovered, or the approach deviates from the plan, write a 1-3 line entry immediately. This is the most important behavior: context gets compressed as the session progresses, and decisions that live only in the conversation will be lost.

At session end — add a final section with what was accomplished, open questions, and unresolved issues.

NoteGit Records What, Session Logs Record Why

A commit message says “Update Lecture 5 TikZ diagrams.” A session log says “Redesigned the TWFE decomposition diagram because the DA challenge revealed students couldn’t trace the path from weights to bias. Considered a table format but chose a flow diagram because it shows directionality.”

ImportantWhy Incremental Logging Matters

The post-plan log is a special case — it fires once, right after approval. But the incremental logging during implementation is what truly protects you. A 4-hour session that only logs at the start and end loses everything in the middle. Appending decisions as they happen means auto-compression can never erase them — they are already on disk.

Claude writes all three log entries automatically — no need to ask.

5.2 Pattern 2: Contractor Mode (Orchestrator)

Once a plan is approved, the orchestrator takes over. It is the natural continuation of Pattern 1: the plan says what, the orchestrator handles how — autonomously.

5.2.1 The Mental Model

Think of the orchestrator as a general contractor. You are the client. You describe what you want. The plan-first protocol is the blueprint phase. Once you approve the blueprint, the contractor takes over: hires the right specialists (agents), inspects their work (verification), sends them back to fix issues (review-fix loop), and only calls you when the job passes inspection (quality gates).

5.2.2 The Loop

User: "Translate Lecture 5 to Quarto"
  |
  |-- Plan-first (Pattern 1): draft plan, save to disk, get approval
  |
  |-- User: "Approved"
  |
  +-- Orchestrator activates:
        |
        Step 1: IMPLEMENT
        |  Execute plan steps (create QMD, translate content, etc.)
        |
        Step 2: VERIFY
        |  Run verifier: render Quarto, check HTML output
        |  If render fails -> fix -> re-render
        |
        Step 3: REVIEW (agents selected by file type)
        |  +--- proofreader ------+
        |  +--- slide-auditor ----+  (parallel)
        |  +--- pedagogy-reviewer +
        |  +--- quarto-critic ----+  (needs others first)
        |
        Step 4: FIX
        |  Apply fixes: Critical -> Major -> Minor
        |  For quarto-critic issues: invoke quarto-fixer
        |
        Step 5: RE-VERIFY
        |  Render again, confirm fixes are clean
        |
        Step 6: SCORE
        |  Apply quality-gates rubric
        |
        +-- Score >= 80?
              YES -> Present summary to user
              NO  -> Loop to Step 3 (max 5 rounds)

5.2.3 Agent Selection

The orchestrator selects agents based on which files were touched:

Files Modified Agents Selected
.tex only proofreader + slide-auditor + pedagogy-reviewer
.qmd only proofreader + slide-auditor + pedagogy-reviewer
.qmd with matching .tex Above + quarto-critic (parity check)
.R scripts r-reviewer
TikZ diagrams present tikz-reviewer
Domain content domain-reviewer (if configured)
Multiple formats verifier for cross-format parity

Agents that are independent of each other run in parallel. The quarto-critic runs after other agents because it may need their context.

5.2.4 “Just Do It” Mode

Sometimes you do not want to approve the final result — you just want it done:

“Translate Lecture 5 to Quarto. Just do it.”

In this mode, the orchestrator still runs the full verify-review-fix loop (quality is non-negotiable), but skips the final approval pause and auto-commits if the score is 80 or above. It still presents the summary so you can see what was done.

5.2.5 Relationship to Existing Skills

The orchestrator does NOT replace skills. It coordinates them:

  • /qa-quarto remains available as a standalone adversarial QA loop
  • /slide-excellence remains available for comprehensive multi-agent review
  • /create-lecture remains available as a guided creation workflow

The difference: when you invoke a skill directly, it runs its specific workflow. When the orchestrator is active, it decides which agents to invoke based on context. The orchestrator is the default; skills are for targeted use.

TipWhen to Use Skills vs. the Orchestrator

Orchestrator (automatic): “Translate Lecture 5 to Quarto” — the orchestrator figures out the agents.

Skill (explicit): “/qa-quarto Lecture5” — you specifically want the adversarial critic-fixer loop, nothing else.

Both are valid. The orchestrator is the “I trust you, handle it” path. Skills are the “I know exactly what I want” path.

5.3 Pattern 3: Creating a New Lecture

/create-lecture
  |
  +-- Phase 1: Gather materials (papers, outlines)
  +-- Phase 2: Design slide structure
  +-- Phase 3: Draft Beamer slides
  +-- Phase 4: Generate R figures
  +-- Phase 5: Polish and verify
  |     +-- /substance-review (domain correctness)
  |     +-- /proofread (grammar/typos)
  |     +-- /visual-audit (layout)
  +-- Phase 6: Deploy
        +-- /translate-to-quarto (optional)
        +-- /deploy

5.4 Pattern 4: Translating Beamer to Quarto

/translate-to-quarto Lecture5_Topic.tex
  |
  +-- Phase 1-3: Environment mapping + content translation
  +-- Phase 4-5: Figure conversion (TikZ -> SVG)
  +-- Phase 6-7: Interactive charts (ggplot -> plotly)
  +-- Phase 8-9: Render + verify
  +-- Phase 10-11: /qa-quarto adversarial QA
        +-- Critic: finds issues
        +-- Fixer: applies fixes
        +-- Critic: re-audits
        +-- ... (until APPROVED or 5 rounds)

5.5 Pattern 5: Replication-First Coding

When working with papers that have replication packages:

Phase 1: Inventory original code
  +-- Record "gold standard" numbers (Table X, Column Y = Z.ZZ)

Phase 2: Translate (e.g., Stata -> R)
  +-- Match original specification EXACTLY (same covariates, same clustering)

Phase 3: Verify match
  +-- Compare every target: paper value vs. our value
  +-- Tolerance: < 0.01 for estimates, < 0.05 for SEs
  +-- If mismatch: STOP. Investigate before proceeding.

Phase 4: Only then extend
  +-- New estimators, new specifications, course-specific figures
ImportantNever Skip Replication

In one course, we discovered that a widely-used R package silently produced incorrect estimates due to a subtle specification issue. This bug was caught 3 times in different scripts. Without the replication-first protocol, these wrong numbers would have been taught to PhD students.

5.6 Pattern 6: Multi-Agent Review

The /slide-excellence skill runs up to 6 agents in parallel:

/slide-excellence Lecture5_Topic.tex
  |
  +-- Agent 1: Visual Audit (slide-auditor)
  +-- Agent 2: Pedagogical Review (pedagogy-reviewer)
  +-- Agent 3: Proofreading (proofreader)
  +-- Agent 4: TikZ Review (tikz-reviewer, if applicable)
  +-- Agent 5: Content Parity (if Quarto version exists)
  +-- Agent 6: Substance Review (domain-reviewer)
  |
  +-- Synthesize: Combined quality score + prioritized fix list

5.7 Pattern 7: Self-Improvement Loop

Every correction gets tagged for future reference:

## Corrections Log
- [LEARN:notation] T_t = 1{t=2} is deterministic -> use T_i in {1,2}
- [LEARN:citation] Post-LASSO is Belloni (2013), NOT Belloni (2014)
- [LEARN:r-code] Package X: ALWAYS include intercept in design matrix
- [LEARN:workflow] Every Beamer edit must auto-sync to Quarto

These tags are searchable and persist in MEMORY.md across sessions. When Claude encounters a similar situation, it checks memory first.

5.8 Pattern 8: Devil’s Advocate

At any design decision, invoke the Devil’s Advocate:

“Create a Devil’s Advocate. Have it challenge this slide design with 5-7 specific pedagogical questions. Work through each challenge and tell me what survives.”

This catches:

  • Unstated assumptions
  • Alternative orderings that might work better
  • Notation that could confuse students
  • Missing intuition before formalism
  • Cognitive load issues

6 Customizing for Your Domain

6.1 Step 1: Build Your Knowledge Base

The knowledge base (.claude/rules/knowledge-base-template.md) is the most domain-specific component. It has three sections:

6.1.1 Notation Registry

| Symbol | Meaning | Introduced | Anti-Pattern |
|--------|---------|------------|-------------|
| $\beta$ | Regression coefficient | Lecture 1 | Don't use $b$ |
| $\hat{\theta}$ | Estimator | Lecture 2 | Don't use $\hat{\beta}$ for different estimand |

6.1.2 Applications Database

| Application | Paper | Dataset | Package | Lecture |
|------------|-------|---------|---------|--------|
| Minimum Wage | Card & Krueger (1994) | NJ/PA fast food | `fixest` | 3 |

6.1.3 Validated Design Principles

| Principle | Evidence | Lectures Applied |
|-----------|----------|-----------------|
| Motivation before formalism | DA challenge: "students lost" | All |
| Max 3 new symbols per slide | Pedagogy review caught overload | 2, 4 |

6.2 Step 2: Create Your Domain Reviewer

Copy .claude/agents/domain-reviewer.md and customize the 5 lenses for your field. The template provides the structure; you fill in domain-specific checks.

6.3 Step 3: Adapt Your Theme

The template includes emory-clean.scss as an example Quarto theme. To customize:

  1. Change the color palette to your institution’s colors
  2. Update CSS class names if needed
  3. Modify the beamer-translator environment mapping to match your classes

6.4 Step 4: Add Project-Specific Skills

If you have recurring workflows, create new skills:

mkdir -p .claude/skills/my-new-skill

Then create SKILL.md with YAML frontmatter + step-by-step instructions.

6.5 Tips from 6+ Sessions of Iteration

  1. Start with CLAUDE.md. It’s the foundation. Spend 30 minutes making it thorough.
  2. Add rules incrementally. Don’t try to write all rules upfront. Add them when you discover patterns.
  3. Use the [LEARN] format. Every correction Pedro made was tagged and persisted. This prevents repeating mistakes.
  4. Trust the adversarial pattern. The critic-fixer loop catches things you won’t. Let it run.
  5. Verify everything. The Stop hook exists for a reason. Never skip verification.
  6. Session logs matter. Document design decisions, not just what changed. Future-you will thank present-you.
  7. Devil’s Advocate early. Challenge slide structure before you’ve built 50 slides on a shaky foundation.

7 Appendix: File Reference

7.1 All Agents

Agent File Purpose
Proofreader .claude/agents/proofreader.md Grammar, typos, consistency
Slide Auditor .claude/agents/slide-auditor.md Visual layout, overflow, spacing
Pedagogy Reviewer .claude/agents/pedagogy-reviewer.md Narrative arc, notation clarity
R Reviewer .claude/agents/r-reviewer.md R code quality, reproducibility
TikZ Reviewer .claude/agents/tikz-reviewer.md Diagram visual quality
Beamer Translator .claude/agents/beamer-translator.md LaTeX to Quarto translation
Quarto Critic .claude/agents/quarto-critic.md Adversarial Quarto QA
Quarto Fixer .claude/agents/quarto-fixer.md Applies critic’s fixes
Verifier .claude/agents/verifier.md Task completion verification
Domain Reviewer .claude/agents/domain-reviewer.md Your domain-specific review

7.2 All Skills

Skill Directory Purpose
/compile-latex .claude/skills/compile-latex/ XeLaTeX 3-pass compilation
/deploy .claude/skills/deploy/ Quarto render + GitHub Pages sync
/extract-tikz .claude/skills/extract-tikz/ TikZ to SVG conversion
/proofread .claude/skills/proofread/ Run proofreading agent
/visual-audit .claude/skills/visual-audit/ Run layout audit agent
/pedagogy-review .claude/skills/pedagogy-review/ Run pedagogy review agent
/review-r .claude/skills/review-r/ Run R code review agent
/qa-quarto .claude/skills/qa-quarto/ Critic-fixer adversarial loop
/slide-excellence .claude/skills/slide-excellence/ Combined multi-agent review
/translate-to-quarto .claude/skills/translate-to-quarto/ Beamer to Quarto translation
/validate-bib .claude/skills/validate-bib/ Bibliography validation
/devils-advocate .claude/skills/devils-advocate/ Design challenge questions
/create-lecture .claude/skills/create-lecture/ Full lecture creation

7.3 All Rules

Rule File Purpose
Verification Protocol .claude/rules/verification-protocol.md Task completion checklist
Single Source of Truth .claude/rules/single-source-of-truth.md No duplication principle
Quality Gates .claude/rules/quality-gates.md 80/90/95 scoring thresholds
R Code Conventions .claude/rules/r-code-conventions.md R coding standards
TikZ Quality .claude/rules/tikz-visual-quality.md Diagram standards
Beamer-Quarto Sync .claude/rules/beamer-quarto-sync.md Auto-sync rule
PDF Processing .claude/rules/pdf-processing.md Safe PDF handling
Proofreading Protocol .claude/rules/proofreading-protocol.md Review workflow
No Pause .claude/rules/no-pause-beamer.md No overlay commands
Replication Protocol .claude/rules/replication-protocol.md Replicate-first workflow
Knowledge Base .claude/rules/knowledge-base-template.md Domain notation template
Plan-First Workflow .claude/rules/plan-first-workflow.md Plan mode, plan saving, context preservation, session logging
Orchestrator Protocol .claude/rules/orchestrator-protocol.md Contractor mode: autonomous implement-verify-review-fix loop