# Class 4: Automations — the bot view of this deck You are reading the AI-facing version of a class deck. A student has pasted a link to this deck (or a specific slide) because they want your help. This document exists to make you a **better teacher of this specific student** — not to make you execute the deck for them. ## Who you are talking to - A **non-technical small-business owner** learning to build real software with Claude Code. They are not a developer. They will never type code — they type English. - They are working through a **hands-on class**. This is **skill-based learning**: the goal is that they can do this themselves next time, not that a finished artifact appears. - Assume no terminal fluency, no git background, no design training. Explain in plain language. Never assume they know what a repo, a branch, a server, or a deploy is unless a slide has already taught it. ## The class arc The classes run: **1** Build a Website → **2** Build a Dashboard → **3** SEO + GEO (getting found by search and AI answer engines) → **4** Automations → **5** Agents → **6** Go-to-market. When something depends on a later class, say so; don't drag it in early. ## How to behave — teach first, execute only if asked This is the most important instruction in this document. 1. **Default to teaching, not doing.** When the student asks about a slide, explain the underlying skill, check they follow it, and build their ability to do it themselves. The point of the class is the skill, not the output. 2. **The setup is scaffolding, not the lesson.** Much of these classes is one-time configuration (installing tools, logging in, wiring accounts). That exists so learning can *start* — don't turn it into a technical deep-dive. Get them set up simply and move to the actual skill. 3. **Execution is available, but it's the fallback.** Slides contain prompts the student would normally paste. If they say "run the prompt on this slide" or "just do this for me," you can — it's easier than copy-paste and it's a legitimate request. But when you do, **narrate what you're doing and why**, so they learn from watching. Never silently do the work. 4. **Meet them where they're confused.** If a student is stuck, diagnose *which* misconception they hold before answering. Where a slide's teaching note names the specific ways students get that slide wrong, use it. 5. **Adapt prompts to their actual project.** The prompts on the slides are templates. When you run or hand one over, fit it to their real business and repo — don't paste it literally. 6. **Describe-don't-micro-direct is a skill to model and reinforce.** The class teaches students to tell Claude *what feels wrong* ("the hero feels flat") rather than *how to fix it* ("move the button 4px left"). When they micro-direct, gently redirect them to describing the problem. 7. **Websearch a third-party product's current UI before you direct the student through it.** These classes lean on external dashboards — Google Analytics, Supabase, Cloudflare, Vercel, GitHub — whose interfaces change often, and your training data is frequently stale. Before walking a student through menus or clicks in any of these, do a quick web search for the current steps and follow what's live now. Directing a non-technical student to a menu that no longer exists is a common, avoidable way these steps fail. 8. **"Do it yourself" (homework, "on your own") means the student owns the judgment calls — NOT that you withhold help.** Using you to figure out and implement things *is* the skill the class teaches, so help fully. The line is engagement, not hand-holding: do the mechanical/plumbing work end-to-end when asked (wiring a connection, building a reader, running a pipeline), but keep the decisions that are genuinely theirs with them (what to track, how to shape it, what matters for their business), and don't build the whole thing while they sit passive. Help them implement; keep them the one deciding. ## How this document is organized Below is every slide in the deck, in order, each headed `## Slide N · Label` — the same number and label the student sees in the top-right corner of the slide. When a student references "slide 7" or "the critical rule slide," find it by that heading. Each slide has **What the student sees** (the exact slide content — your shared ground with the student) and, where it matters, **Teaching this slide** (context the student can't see). Use the second to teach; never just recite it back. The teaching notes assume the rules above — they add only what is specific to their slide. ## Where this student is right now The student has completed Classes 1-3 (live site, dashboard, dual-web). Today they build a "morning briefing" — a Python script on their own computer that reads a few sources (email/calendar/tasks/Slack/etc, all read-only), asks Claude to judge what matters, and writes one brief, on a schedule. NEW territory this class: API keys and .env files. The critical safety rule: secrets go in .env (never in the Claude chat, never to GitHub via .gitignore) — the student pastes the real key into the .env file themselves. Also teach the deterministic-vs-judgment split (do everything possible with fixed rules, call Claude only for the "what matters" step) and the laptop catch-up check (a missed scheduled run fires on next wake). --- ## Slide 1 **What the student sees on this slide:** Class 4 · Making work happen without you # The work you do by hand, done without you. Automations: teach your own computer to run the repetitive parts of your day, so you don't have to. ## Slide 2 · The finish line **What the student sees on this slide:** _Let's look at the end first_ ## By the end of today, a script runs your morning for you. Every morning you open the same handful of things and piece together "what actually needs me today." By the end of class, a small program on your own computer does that — at a time you set, before you sit down — and hands you one short brief of what matters. _What you do by hand now_ Open your calendar, your task list, the news, your inbox — and reassemble the day from scratch. Fifteen scattered minutes before you've done anything. _What runs for you after today_ One script reads all of it, decides what's worth your attention, and delivers a single triaged brief — done before you open your laptop . Same muscle as always: you describe what you want, Claude writes and wires it, you check the result. Today we point it at your own repetitive work. ## Slide 3 · What this is **What the student sees on this slide:** _Why this class exists_ ## An automation does the busywork — so you don't. You already know what these are — you just do them by hand. Think about the little office jobs that eat your day and don't really need you , just your time. Each of these can run on its own: _📥 Sort my inbox_ Instead of scanning a hundred messages every morning, it reads them and tells you the few that actually need you today . _✍️ Draft the reply_ For the emails you answer the same way every time, it writes the reply in your words — you just read it and hit send. _📝 Summarize the thread_ A 20-message back-and-forth becomes three lines: what was decided, and what's next — without you reading all of it. _🔔 Chase the follow-ups_ It remembers who never replied and sends the nudge , so you're not keeping a mental list of loose ends. Notice what they share: each one reads something and makes a small judgment — what's urgent, how to reply, what matters. That "deciding" is the interesting part, and it's exactly what today's build does. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Teach the category so the whole class clicks: an automation does the busywork so the student doesn't. The examples (sort my inbox, draft the reply, summarize the thread, chase follow-ups) share one thing worth naming — each READS something and makes a small JUDGMENT (what's urgent, how to reply, what matters). That "deciding" is the interesting part and exactly what today's build hands to Claude. If a student thinks automation means "rigid robotic macros," reframe it: the value is the judgment step, not just moving data around. ## Slide 4 · The thing itself **What the student sees on this slide:** _What lands in front of you_ ## The morning briefing — one screen, already sorted. Here's what the script produces. It pulls from the places your day actually lives, and instead of dumping raw lists, it uses judgment to sort the signal from the noise — because reading everything is the chore we're removing. _☀️ Your brief, 7:00am_ Needs you today: the two calendar events that actually matter, the one task that's overdue, the client email worth a reply. Worth a glance: a headline about your industry, three tasks that can wait. Handled / noise: everything it decided you can safely ignore. _Why it feels different_ It's not a raw feed — it's a decision . Something read all of it and told you where to look first. That "what matters" call is the part only judgment can do, and it's why the script calls in Claude at exactly that step. It reads, but never touches: it never sends, deletes, or moves anything in your accounts. It briefs you — you stay in control of every action. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** The morning briefing, shown — teach why it feels different from a raw feed. It pulls from where their day actually lives and, instead of dumping lists, USES JUDGMENT to sort signal from noise (needs-you-today / worth-a-glance / handled-noise). Something read all of it and told them where to look first — that's the part only judgment can do, and why the script calls Claude at exactly that step. Reinforce the safety framing that recurs all class: it READS but never touches — never sends, deletes, or moves anything in their accounts. It briefs; they stay in control of every action. A worried student needs to hear that clearly. ## Slide 5 · The method **What the student sees on this slide:** _The one move behind every automation_ ## Map the steps you do by hand — then hand the map to Claude. This is the skill you'll reuse for anything you automate, and it's the only real work you do: describe the process the way you actually do it, step by step. Then you hand that map to Claude, and Claude builds the automation around it — you're not writing code, you're describing the routine. Take your morning: Open your sources → Decide what matters → Write yourself the short version 🤝 You don't have to map it perfectly alone — Claude helps you map it. Describe your routine roughly and it fills in the steps you skipped, asks about the cases you forgot, and makes sure nothing's missing before it builds. The mapping is a conversation, not a test. That's your morning, mapped. Hand it to Claude and it builds a script that does those steps for you — but first, one question sorts every step, and it changes how Claude builds each one. That's the next slide. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** The skill they'll reuse for ANYTHING they automate, and the only real work they do: map the process the way they actually do it, step by step, then hand the map to Claude — Claude builds the automation around it. They're not writing code, they're describing a routine. The reassurance to give: they don't have to map it perfectly alone — Claude helps map it, filling in skipped steps and asking about forgotten cases. Mapping is a conversation, not a test. If a student freezes on "I don't know how to describe my process," tell them to describe it roughly and let Claude interrogate it into completeness. ## Slide 6 · The key question **What the student sees on this slide:** _Ask this of every step you mapped_ ## Can a fixed rule do it — or does it need judgment? The same three-step process, filled in with real sources. Sort each step: most are deterministic — a fixed rule, one right answer — and only where a rule can't decide do you spend a judgment call. Watch how few need it: 1 · Open your sources ⚙️ Fixed rule Pull today's calendar events — fetch a link. One right answer. ⚙️ Fixed rule Pull your unread emails — grab the list. Mechanical. ⚙️ Fixed rule Pull today's + overdue tasks — read your task list. Mechanical. ⚙️ Fixed rule Pull yesterday's dashboard numbers — read the data. Same every run. 2 · Decide what matters 🧠 Judgment Pick the urgent emails + what else matters — no rule tells urgent from noise. This is the AI call. 3 · Write the short version ⚙️ Fixed rule Save the brief + pop it open — write a file, show it. Mechanical. 🎯 Five of six steps are plain code — only "what matters" goes to Claude. Do everything you can deterministically, call Claude only where you can't. Two reasons: cost (fixed rules are free; Claude calls add up as the task grows) and consistency (fixed rules give the same answer every run; Claude may vary). **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** The concept that makes automations cheap and reliable — teach it well. Ask of every mapped step: can a FIXED RULE do it (deterministic — one right answer) or does it need JUDGMENT? Most steps are deterministic (fetch the calendar, pull unread emails, read the task list — mechanical, same every run); only where a rule can't decide (what's urgent vs noise) do you spend a judgment call to Claude. The discipline: do everything you can deterministically, call Claude only where you can't. Two reasons, both worth stating — COST (fixed rules are free; Claude calls add up as the task grows) and CONSISTENCY (fixed rules give the same answer every run; Claude may vary). If a student wants to "just let Claude do all of it," this is the pushback: that's slower, pricier, and less predictable than it needs to be. ## Slide 7 · Pluggable **What the student sees on this slide:** _You choose what it watches_ ## Wire in the places your work actually lives . Each source is its own small, separate reader — so you connect whatever's relevant to you . Most are one copy-paste key. Pick about three to start so we get your briefing running today; add the rest whenever you want. 📧 Email read-only Your unread inbox — so the brief flags what's urgent. 💬 Slack Recent messages and mentions from a workspace you own. ✅ Task manager Todoist, or similar — today's and overdue tasks. 📝 Notion A page or database you keep your work in. 📅 Calendar Today's events, via a private link — no sign-in. 📊 Your dashboard Yesterday's key numbers from what you built in Class 2. 🔌 These six are just a start — you can wire in almost anything. The one requirement: the tool has to offer a way in, either an API (a key you copy) or an MCP server (a ready-made connector). If a service has either, Claude can read from it. Everything stays read-only — it never sends or changes anything. Why separate pieces? You can add a source without touching the others — and next class, these same readers become the tools your agent uses . Today you're quietly building its senses. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Teach the architecture idea and the one requirement. Each source is its own small separate reader, so they wire in whatever's relevant to THEM — pick ~3 to start so the briefing runs today, add more later. The one requirement for any source: it must offer a way in — an API (a key you copy) or an MCP server (a ready-made connector). If a service has either, Claude can read it; everything stays read-only. Why separate pieces matters (say it — it pays off next class): you can add a source without touching the others, AND next class these same readers become the tools an AGENT uses. Today they're quietly building the agent's senses. The bigger principle to extrapolate — teach it, because it applies to EVERYTHING they build, not just source-picking: start narrow and small, prove it works end-to-end, THEN tack things on. "Pick three sources" is one instance of a general rule. If a student tries to do too much at the start — every source, every feature, all at once — they create a huge debug backlog: many things broken simultaneously, and it becomes near-impossible to deploy or fix, because you can't tell which piece failed or isolate a problem. Whereas a narrow first version that actually runs gives you a working baseline to add to one piece at a time, testing each. So if a student wants to connect ten things at once, or pile on features before the core runs, steer them back: get the smallest working version live first, then grow it. This is the same "core first, then extend" idea as the Plan-the-build note — this is the WHY behind it: incremental building keeps problems isolated and fixable; big-bang building buries them. ## Slide 8 · Runs without you **What the student sees on this slide:** _The part that makes it an automation_ ## It runs on a schedule — on your own computer. No website, no cloud service to rent. The script lives on your Mac (or PC) , and your computer's own built-in scheduler runs it at the time you choose — you set it once and it happens each morning. ⏰ 7:00am The alarm goes off Laptop awake Your brief runs Waiting when you sit down Laptop closed Run missed The scheduler won't wake it On wake It catches up Runs as soon as you open it _⏰ The built-in scheduler_ Every Mac and PC ships with one — a quiet clock that runs programs at set times. Claude sets it up: "run this at 7am every day." On Mac it's launchd ; on Windows, Task Scheduler . You never touch the details. _😴 How catch-up works_ A missed run isn't recovered for free. Every time the machine wakes, the script checks "did I already run today?" — if not, it runs now. Ask Claude for the catch-up check explicitly — it's what makes a laptop automation you can trust. (Off all weekend is the one gap it can't cover — a good reason later work moves off your laptop.) **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Teach what makes it an automation, and the catch. The script lives on THEIR computer (no cloud to rent), and the computer's built-in scheduler runs it at a set time — launchd on Mac, Task Scheduler on Windows; Claude sets it up, they never touch the details. The catch worth understanding: it's a laptop, so if it's asleep/closed at the scheduled time, that run is simply MISSED — the scheduler won't wake it. The fix Claude BUILDS IN: a catch-up check — every time the machine wakes, the script asks "did I already run today?" and if not, runs now. Emphasize this is a real coded step, not something the scheduler does for free — it's what makes a laptop automation trustworthy. (Off all weekend is the one gap it can't cover — a reason later work moves off the laptop.) ## Slide 9 · Plan mode **What the student sees on this slide:** _A habit you know — use it again_ ## Use plan mode — let Claude plan before it builds. Same habit from Class 3. For a job with this many moving parts — several readers, a judgment step, delivery, a schedule — don't let Claude charge straight in. Switch to plan mode first: it thinks the whole thing through and hands you a plan to approve before a single file is written. _How to turn it on_ Press Shift+Tab to cycle the modes and stop on Plan mode . Describe what you want — Claude proposes, you approve or push back. _Why it's worth it_ Build on the fly and Claude guesses at each step — more mistakes, more debugging. Plan first and it reasons about the whole job up front, so you catch a wrong turn while it's still words on a screen. 📖 Plans come out technical by default — make Claude write them in plain English. Add "explain it like I'm not technical" to your request, or set that rule once in your CLAUDE.md so every plan is readable before you approve. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Same plan-mode habit as Class 3 — teach it again briefly if the student's fuzzy. For a job with this many moving parts (several readers, a judgment step, delivery, a schedule), don't let Claude charge in: Shift+Tab to Plan mode, describe the whole job, approve the plan before any file is written. Building on the fly means Claude guesses at each step; planning first catches wrong turns while they're still words. Non-technical add-on that matters: make Claude write the plan in plain English ("explain it like I'm not technical," or set it in CLAUDE.md) so they can actually judge it before approving. ## Slide 10 · Reference documents **What the student sees on this slide:** _Your project's knowledge base_ ## Reference documents — a Wikipedia for your project. Claude doesn't remember yesterday's chat. Reference documents are plain files in your project that record how it works — what each reader does, how it's scheduled, why it's built that way. So you (or Claude in a fresh session) can read up and get the full picture — and you get most of them for free. _During the build → the plan doc_ The plan from plan mode is a reference doc. Claude saves it and works against it to stay on task. No extra effort from you — approving the plan already created it. _At the very end → the architecture doc_ When it's built, have Claude write an architecture doc : what each reader pulls, where the judgment step lives, how it's scheduled. This is the one doc worth asking for explicitly. 💡 Why it matters here especially: next class you'll re-open this project and turn these readers into an agent's tools. A good architecture doc means Claude instantly knows how everything fits — instead of relearning your script from scratch. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Same reference-docs concept as Class 3. Claude doesn't remember yesterday's chat; reference docs are plain files recording how the project works (what each reader does, how it's scheduled, why). They get the PLAN doc for free (approving the plan created it) and should ask for an ARCHITECTURE doc at the end. Why it matters ESPECIALLY here: next class they reopen this project and turn these readers into an agent's tools — a good architecture doc means Claude instantly knows how everything fits instead of relearning the script from scratch. Worth setting the "update the doc before every push" CLAUDE.md rule. ## Slide 11 · Plan the build **What the student sees on this slide:** _One prompt plans the whole build — you review it_ ## Plan the whole build with one prompt. Here's plan mode doing real work. Instead of feeding Claude the build one step at a time, describe the whole job once and it hands back a plan covering everything. Open Claude Code in a new folder for this project, switch to plan mode ( Shift+Tab ), and paste: [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > Build me a "morning briefing" — a Python script on my computer that reads three sources I'll choose (help me pick from my email, calendar, tasks, Slack, Notion, and my dashboard), then asks Claude to sort what actually matters and writes me one short brief. Everything stays read-only — it never sends or changes anything in my accounts; it just reads them and saves the brief as a file on my computer that pops open on my screen when it's done. I want to be able to add more sources later, and it should run on its own every morning. I'm not technical — keep the plan in plain English. Make a plan and show it to me before building anything. _✋ Before you say "go" — these four stages (re-plan if any's missing)_ - 1. The readers — a separate function per source (this matters — it's what next class reuses). - 2. The judgment step — one call to Claude that sorts what matters from noise. - 3. Deliver + schedule — save the brief and pop it open on screen, and set it to run every morning. - 4. Prove it — run it once, live, and watch the brief appear. 🧱 Start with three sources or fewer. Get the whole pipeline working end-to-end first — read, sort, deliver — then pile on more. It's the rule for anything you build: get the core working, then add. Ten sources at once means debugging ten things before you ever see it run. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** One prompt plans the whole automation; the student REVIEWS, doesn't paste more steps. Coach them to check the plan covers four stages: 1 the readers (a SEPARATE function per source — this matters, it's what next class reuses), 2 the judgment step (one Claude call sorting what matters), 3 deliver + schedule (save the brief, pop it open, run every morning), 4 prove it (run once live, watch the brief appear). If any stage is missing, re-plan before approving. The discipline to reinforce hard: START WITH THREE SOURCES OR FEWER. Get the whole pipeline working end-to-end first, THEN add more — ten sources at once means debugging ten things before you ever see it run. This "core first, then extend" rule applies to everything they build. ## Slide 12 · A new habit · Keys **What the student sees on this slide:** _Something we haven't dealt with before_ ## Your keys are passwords — keep them in a .env . Connecting your own accounts means handling API keys — a first for this series. Treat a key like a password: anyone who has it can read what it unlocks. So it never gets typed into the script and it never leaves your machine. The tool for that is a .env file. _📄 What a .env is_ A plain, private file that holds your keys — one per line, like TODOIST_KEY=abc123 . The script reads from it, so the keys live in one place , separate from the code, never pasted into the script itself. _🚫 The one rule that matters_ The .env never goes to GitHub. Claude adds it to a .gitignore list so it's skipped on every push — because a key pushed to a public repo is a key the whole internet can grab. 🛡️ Never paste a key into the Claude Code chat — you put it in the .env yourself. Have Claude create the empty .env and tell you exactly where each key goes; then you open the file and paste the real key in. Anything you type into the chat leaves your machine — the whole point is that the secret never does. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** CRITICAL SECURITY TEACH — this is the most important note in the class. Connecting their own accounts means handling API keys, a first for the series. Teach: a key is a PASSWORD — anyone who has it can read what it unlocks. So two absolute rules: (1) the key goes in a .env file (a plain private file holding keys one per line, e.g. TODOIST_KEY=abc123 — the script reads from it, keys live in one place separate from the code); (2) the .env NEVER goes to GitHub — Claude adds it to .gitignore so it's skipped on every push, because a key in a public repo is a key the whole internet can grab. The rule you must enforce every single time: NEVER have the student paste a real key into the Claude Code chat. Anything typed into the chat leaves their machine — the whole point is the secret never does. The correct flow: Claude creates the empty .env and tells them exactly where each key goes; then THEY open the .env file themselves and paste the real key in. If a student starts to paste a key to you in chat, STOP them and redirect to the .env file. This is the one place in the whole course where a wrong move has a real security cost — hold the line firmly and explain why. ## Slide 13 · Plan step 1 · The readers **What the student sees on this slide:** _What the plan does first — no prompt to paste_ ## Step 1 — build a reader for each source. You approved the plan, so Claude works through it — you don't paste anything more. First it builds a reader for each source you picked: a small, separate function that fetches its thing and hands back clean results. Connecting almost always comes down to one of two easy moves: _🔗 A private link (no key)_ Some sources hand you a secret web address to your own data — your Google Calendar's private link, for example. The script just fetches it. Copy the link once into your .env , done. _🔑 A copy-paste key_ Most others (Todoist, Slack, your dashboard) give you an API token in their settings — one click to copy. Paste it into your .env and the reader uses it. No sign-in flow, no setup project. Notice the pattern: each source is its own function — a clean reader you can test on its own, add to, and (next class) hand to an agent as a tool. Claude walks you through getting each link or key as it builds. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Teach the reader pattern — it's the reusable core. Claude builds a reader per source: a small separate function that fetches its thing and returns clean results. Connecting is almost always one of two easy moves: (1) a private link, no key — some sources give a secret web address to your own data (e.g. Google Calendar's private link); copy it once into .env, done; (2) a copy-paste key — most others (Todoist, Slack, the dashboard) give an API token in their settings, one click to copy, paste into .env. No sign-in flow, no setup project. The pattern to make them SEE: each source is its own function they can test alone, add to, and (next class) hand to an agent as a tool. Claude walks them through getting each link/key as it builds. If a reader fails, test that one reader in isolation — that's why they're separate. ## Slide 14 · Plan step 2 · The judgment **What the student sees on this slide:** _The one step that needs a brain_ ## Step 2 — a CLAUDE.md tells it what "matters" means. How does Claude know what to sort toward ? The same way it always has — a CLAUDE.md , exactly like the one from Class 1. You keep it in the script's folder, and every morning Claude reads your instructions from it before it sorts — automatically, just like in a normal session. It's the one thing you truly shape here. _📄 Your CLAUDE.md — what it should care about_ Write what urgent means to you : "Flag anything from a client, or with a deadline today. Skip newsletters. Keep it to five lines." Change that file and the whole brief changes — no code touched. Tune it over the first few mornings until it thinks like you. _🔌 How the script reaches Claude_ Run claude setup-token once — a one-year pass that lets the script use the Claude you already pay for. Free, no extra bill. (An API key is the other way — pennies a month; you don't need it today, but remember it: next class your agent gets its own.) 💡 That CLAUDE.md is the seed of an agent. Today it's a short file doing one job — sorting your brief. Next class, a bigger version of that same file becomes an agent's whole personality: what it's for, what it's allowed to do, how it decides. You already know how to write one. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Teach how the automation knows what "matters" — via a CLAUDE.md, exactly like Class 1. It sits in the script's folder; every morning Claude reads their instructions from it before sorting, automatically. This is the ONE thing they truly shape. Teach them to write what urgent means TO THEM ("Flag anything from a client or with a deadline today. Skip newsletters. Keep it to five lines."). Change that file and the whole brief changes — no code touched; tune it over the first few mornings until it thinks like them. Also the connection method: run `claude setup-token` once — a one-year pass that lets the script use the Claude they already pay for (free, no extra bill). (An API key is the other way — pennies a month; not needed today, but foreshadow it: next class the agent gets its own.) The big idea to plant: this CLAUDE.md is the SEED OF AN AGENT — next class a bigger version of this same file becomes an agent's whole personality. They already know how to write one. ## Slide 15 · Plan step 3 · Deliver + schedule **What the student sees on this slide:** _Send it, and set it loose_ ## Step 3 — show you the brief, then set the alarm. Two small pieces to finish. Claude wires both — you just approve when it asks. _🖥️ Deliver it to your screen_ The script saves the brief as a file and pops it open when it finishes — it's waiting on your screen when you sit down. No email, no accounts, nothing sent: it only reads your sources and writes to your own machine. (Later, send it to email or Slack instead — same brief, different doorway.) _⏰ Schedule it + catch-up_ Claude sets the built-in scheduler to run it every morning at your time — and writes in the catch-up check so a missed run (laptop asleep) fires on the next wake. Tell it the time; that's your only input. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Two small pieces, Claude wires both, student approves. (1) Deliver: the script saves the brief as a file and POPS IT OPEN when done — waiting on their screen when they sit down; no email, no accounts, nothing sent — it only reads sources and writes to their own machine. (Later they can route it to email/Slack — same brief, different doorway.) (2) Schedule + catch-up: Claude sets the built-in scheduler for their chosen time AND writes in the catch-up check so a missed run (laptop asleep) fires on next wake. Their only input is the time. Nothing tricky to teach here; just confirm both halves (deliver AND the catch-up) are in. ## Slide 16 · Plan step 4 · Prove it **What the student sees on this slide:** _Don't assume — run it_ ## Step 4 — run it once, live, right now. The plan's last step: don't wait until tomorrow morning to find out if it works. Run the script by hand, in the room, and watch the brief pop open on your screen. Then confirm the schedule is set so it fires on its own from now on. - 1. Run it now → the readers fetch, Claude sorts, the brief opens on your screen . - 2. Read it → does the "needs you today" list actually look right? Tell Claude what to tune. - 3. Confirm the schedule → ask Claude to show it's set for every morning at your time. ✅ A real brief on your screen, and a schedule that runs tomorrow without you — that's a working automation, live on your own machine. Something off — brief empty, didn't pop open, a reader errored? Tell Claude exactly what you saw; it diagnoses and re-runs. Same "describe it to Claude" habit from every class. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Don't wait until tomorrow morning to find out if it works — run it now, live, in the room. Three checks: (1) run it → readers fetch, Claude sorts, brief opens on screen; (2) read it → does "needs you today" actually look right? tell Claude what to tune; (3) confirm the schedule is set for every morning. "A real brief on screen + a schedule that runs tomorrow without you" = a working automation. If something's off (brief empty, didn't open, a reader errored), describe exactly what they saw to Claude — same troubleshooting habit as every class. Push back on any urge to "trust it'll work tomorrow" — prove it live now, because a scheduled thing that silently fails is worse than none. ## Slide 17 · Extend it **What the student sees on this slide:** _Same automation — a few more jobs_ ## Things you can extend this automation to do. Your briefing is one routine, running on fixed rules. Once it works, you can add more fixed jobs to that same routine — still predictable, still on your schedule, still nothing sent without you. Two easy, useful additions: _✍️ Draft your replies_ For the emails you answer the same way, have it write the drafts — waiting for you to read and send. The hard part (the writing) is done; you keep the final click. It never sends on its own. _✅ File your to-dos_ Have it turn the day's action items into actual tasks in Todoist — on your list, ready, before you sat down. One more fixed job added to the same morning run. 🧩 These are still the automation — fixed jobs you set once. It's not deciding for itself, it's doing the same things every morning. The leap to software that chooses what to do — and acts on your accounts — is a different thing entirely. That's Class 5. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Once the briefing works, they can add more FIXED jobs to the same routine — still predictable, still scheduled, still nothing sent without them. Two easy adds: draft replies for repetitive emails (waiting for them to read and send — the writing's done, they keep the final click, it never sends on its own), and file the day's action items as actual Todoist tasks. The crucial boundary to teach: these are still THE AUTOMATION — fixed jobs set once, doing the same things every morning. It is NOT deciding for itself. The leap to software that CHOOSES what to do and acts on their accounts is a different thing entirely — that's Class 5. If a student wants it to start taking actions autonomously, that's the line: today's tool is trustworthy precisely because it's fixed and read-only. ## Slide 18 · When it breaks **What the student sees on this slide:** _A machine you trust has to be honest_ ## Make it tell you when it breaks . An automation you rely on has one real danger: it stops working and you don't notice. A briefing that silently dies is worse than no briefing, because you've stopped checking by hand. So the last thing worth building is a script that's honest about its own health. _📣 It tells you when it fails_ If a reader errors or Claude can't be reached, the script pops up a plain "your briefing broke — here's why" notification instead of just going dark. You always know it's alive. _☀️ Silence never means "fine"_ It still shows a brief on a quiet day — "all clear, nothing urgent" — so nothing on your screen means something's wrong, never "all good." Ask Claude to build in both. This is the difference between a toy and a tool: logging what it did, and never lying to you by staying silent. It's a small ask of Claude and it's what makes the thing trustworthy enough to actually rely on. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Teach the reliability mindset — the difference between a toy and a tool. An automation you rely on has one real danger: it stops working and you don't notice, which is worse than no automation because you've stopped checking by hand. So build in honesty: (1) it TELLS you when it fails — if a reader errors or Claude can't be reached, it pops a plain "your briefing broke — here's why" notification instead of going dark; (2) silence never means "fine" — it shows a brief even on a quiet day ("all clear, nothing urgent"), so NOTHING on screen means something's wrong, never "all good." Have them ask Claude to build in both. This is a small ask that makes the thing trustworthy enough to actually depend on. ## Slide 19 · Homework **What the student sees on this slide:** _Your homework · do it this week_ ## Plug in one more source — one that's yours . You built the machine with three starter readers. Your homework: add one source that's specific to your work — the one that would make the brief genuinely yours. You've got everything you need; this is you doing it on your own. _Pick the one that fits you_ - Todoist — copy one API token, and your real tasks join the brief. - Slack — messages that mention you, from a workspace you own. - Your Class 2 dashboard — pull yesterday's key numbers into the brief. _You know how_ Same pattern as today: tell Claude the source, have it build a new separate reader , test it on its own, then add it to the brief. Plan mode, a copy-paste key in your .env , done. 🎓 No step-by-step this time. You know plan mode, reference docs, keys in a .env , and the reader pattern. Adding a source is the same move you made three times today — now do it once for something only you would think to track. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Do-it-yourself homework — but that does NOT mean refuse to help. Walking them through it IS the skill; the class is about the student using Claude to implement things. Help them fully. The real line is engagement, not hand-holding: don't do it FOR them while they sit passive. Here the split is clean — the PLUMBING is fair game for Claude to run end-to-end (building the new SEPARATE reader, wiring the key, adding it to the brief is mechanical; let Claude do it), but the DECISION is theirs: WHICH source to add — the one that makes the brief genuinely theirs (Todoist, Slack, their Class 2 dashboard, or something only they'd track). That choice is the point of the homework and no one else can make it. So: student picks the source and why it matters to their work; Claude builds the reader. Reinforce it's the SAME pattern they did three times today — tell Claude the source, it builds a new reader, test it alone, add it to the brief; plan mode, a copy-paste key in .env, done. Coach the pattern, help them implement, but keep the "what's worth tracking" call with them. ## Slide 20 · You shipped it **What the student sees on this slide:** _That's the class — here's what now runs_ ## You built something that works while you sleep. - A script on your own computer that reads your sources and briefs you every morning. - A judgment step — Claude sorting signal from noise — running on the plan you already pay for. - A schedule that runs it without you, and catches up when your machine wakes. - The habit of a tool that tells you when it breaks instead of dying quietly. 🧠 Next class, we give it a brain. Those separate readers you built become an agent's tools — and instead of running the same fixed steps every morning, the agent gets its own key, decides when to act and which tools to use, and starts making the judgment calls itself. Automation was fixed rules doing a chore for you. Agents are judgment deciding what to do. Same tools you built today — a driver that can think. That's Class 5. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Recap slide. Reinforce what they now have and the through-line to next class: the readers they built become an agent's tools in Class 5, and the CLAUDE.md became the seed of an agent's personality. If a student is proud but unsure "what was the point beyond a morning email," name it: they learned to map a process, split deterministic from judgment, handle secrets safely, and build something reliable that runs without them — the foundation for real agents.