A single, carefully structured prompt is enough to have Claude Code build a full AI tutor web app for lecture slides — one that explains each slide out loud, answers questions, and never hallucinates facts.
The AI tutor sits between the instructor's slides and the student's screen: it reads a lecture deck once, then explains it and answers questions forever, without ever re-reading — or misreading — the original PDF.
Paste this directly into Claude Code in an empty project folder. Every bullet encodes a specific design decision — explained one by one below.
Build an AI tutor web app for lecture slides.
- Instructors upload a lecture PDF into a course. Students enroll and open
a lecture: the slide renders on the left, page by page; on the right,
the AI streams a spoken-style explanation of that exact slide.
Students can also ask it questions in a chat panel.
- Anti-hallucination design: don't let the model read the raw slide when
answering. First, turn every slide into a structured "skeleton note"
(title, body, key facts, common misconceptions) using a vision-capable
LLM call, once, at upload time. Every later explanation and every
answer must be generated from these notes only — never the raw PDF —
so the model can't invent facts, and the expensive step never repeats.
- Pre-bake, don't generate live: write the slide-by-slide explanation for
each lecture once (as one continuous conversation, so it reads like a
real lecture), cache it, and replay it to every student for free.
Only Q&A is generated live, per question.
- Progressive disclosure: the tutor may discuss anything up to the
slide the student is currently on, but must refuse to teach ahead —
it just says which slide covers it.
- Continuity across lectures: summarize each lecture into a short
"what this course has covered so far," fed into later lectures'
explanations and Q&A, so the tutor can connect ideas across weeks
without re-reading every past deck.
- Guardrails: cap questions per day and per conversation; auto-detect
and softly refuse off-topic questions, temporarily blocking repeat
offenders; keep all limits admin-tunable and invisible to students
until they're hit.
- Access control: instructors own courses; students must be enrolled in
a course to see any of its slides, explanations, or chats; add an
admin role for usage/cost dashboards and account management.
- Everything the AI generates (notes, explanations, summaries) should be
viewable and hand-editable by the instructor, with old versions kept.These aren't arbitrary requirements — each one closes a specific failure mode you'd hit if you just asked for "an AI tutor app."
Skeleton notes stop hallucination at the source
If the model re-reads the raw slide image every time it explains or answers, small misreadings compound and different answers can drift and contradict each other. Extracting a structured note once, at upload time, gives every later generation the same fixed set of facts to draw from — and gives the instructor one artifact to check for correctness instead of infinite live generations.
Pre-baking trades a one-time cost for free replay
Generating a fresh explanation for every student who opens the same slide is wasteful and lets the same slide get explained differently to different students. Writing the lecture's explanation once, end-to-end, as a single conversation makes it read coherently like an actual lecture — and every student after the first gets it for free. Only genuinely per-student work (answering a specific question) should hit the model live.
Progressive disclosure protects the syllabus pace
An unrestricted tutor will happily explain next week's material to a student who asks ahead, undercutting the instructor's pacing. Telling the model exactly which slide index the student is on, and instructing it to redirect ("that's covered in Lecture 5") rather than answer, keeps the tutor a supplement to the course — not a replacement for its structure.
Cross-lecture summaries give memory without re-reading everything
Feeding the model every past deck on every request gets expensive and slow as a course grows. A short running summary — "what this course has covered so far" — is cheap to carry forward and is usually all the model needs to connect a new idea back to something taught three weeks ago.
Guardrails keep cost and misuse in check without punishing normal use
Per-day and per-conversation question caps put a ceiling on API cost per student. Off-topic detection stops the chat from becoming a general-purpose assistant. Keeping the limits invisible until hit, and admin-tunable, means the product feels unrestricted to a student behaving normally, while still being controllable by whoever is paying the API bill.
Enrollment-based access control matches how courses actually work
Slides, explanations, and chat history are course material — they should be gated the same way a real classroom is: instructors own their courses, students see only what they're enrolled in, and an admin role exists separately for anyone who needs usage and cost visibility across the whole system.
Editable, versioned AI output keeps the instructor in control
AI-generated notes, explanations, and summaries will occasionally be wrong or phrased poorly. Making every generated artifact viewable and hand-editable — with old versions kept — means the instructor can correct a mistake once and have it stay fixed, instead of re-generating and hoping the model gets it right the second time.
Once the first version is running, keep iterating with simple, direct requests.
Ask Claude to let instructors correct a specific extracted fact.
Ask Claude to expose admin-tunable limits in a settings page.
Ask Claude to change how students join a course.
Ask Claude to extend the admin dashboard.
A few things that make this workflow much more reliable.
Get PDF upload → skeleton note extraction → pre-baked explanation working end-to-end for one lecture first. A working pipeline is easier to debug than a full app with a broken core.
Since every later step depends on them, a bad note at upload time will quietly poison every explanation and answer generated from it. Spot-check a few slides after the first upload.
Ask the tutor a question about a later slide while on an earlier one, and confirm it redirects instead of answering. This is easy to get subtly wrong and easy to verify.
Instead of "make the guardrails better," describe the exact behavior you want changed. Specific requests get fixed faster and more accurately.