Warm open. "By the end of today you won't be a programmer — and you don't need to be. You'll have a genuinely capable assistant living inside your computer that does real work for you, in plain English."

Set expectations: we go slow, nothing you do can break anything, and every question is a good question. Tell them the whole session is hands-on — they'll be driving by the end.

Housekeeping: point out they can press S to see these same notes on their own copy later, and M to jump around. Use the ◐ button to flip light/dark for the room.

Orientation lowers anxiety. "By the end you'll have installed it, talked to it, and done a real task — and you'll have a cheat sheet and these slides to take home."

Set the tone: "There are no silly questions today, and nothing you type can break your computer. If you're lost at any point, say so — chances are someone else is too."

The fear in the room is "this is a coder tool, I'll be lost." Defuse it immediately. The skill we're teaching is delegation and review — something everyone here already does with people.

Analogy that lands: "It's the difference between doing the task yourself, versus having a capable assistant do it while you stay the manager."

Emphasise the leap: a chatbot talks; Claude Code acts — on your real files, on your machine. That's the whole "wow."

Reassure again on the terminal: "The terminal looks intimidating — it's just a text box where you type instead of click. We'll demystify it in five minutes."

This is the single most important slide for changing behaviour. People who struggle are almost always using the "vending machine" model.

Reinforce: "You'd never expect a new hire to nail a task with a one-line brief and zero feedback. Same here. A 20-second correction turns a 6/10 into a 10/10."

Set realistic expectations early so nobody feels the tool "failed" when they used it for the wrong thing. The distinction that matters: files on your computer → Claude Code; a quick question → the website.

Reassure the hesitant: "You already use the Claude website? Great — this is the same brain, but it can now open and work on your files directly."

Name the fear directly: "The number one worry is 'what if I delete something important?' Here's why that's very hard to do by accident."

Demo if live: make an edit, then hit Esc Esc to show the rewind. Then show a duplicated backup folder. Confidence comes from seeing the undo, not hearing about it.

Adapt this slide to Fibernetics' actual data policy before presenting — the rules here are sensible defaults, not official policy. Confirm with whoever owns data governance.

Frame it as empowering, not scary: "These aren't hurdles — they're the same judgment you already use with any customer information. When unsure, the answer is always 'ask,' and that's encouraged."

Reassure on where data goes: Claude Code runs on their machine under the company plan; it's not posting their files to a public website. The rule is about their habits (don't paste secrets), not distrust of the tool.

Have everyone download the Setup Guide now — it's the written, self-paced version of the next few slides. They follow the slides with you, and lean on the guide when they get ahead or stuck.

Set the frame honestly: "Setup is the one fiddly part of the whole day. We do it together, once, slowly — after this it's smooth sailing." Reassure that copy-pasting a command is not 'coding.'

Give them the map for the next few slides out loud: PowerShell → add Ubuntu → make a Claude account → install Claude → log in. Four steps.

Plain-English analogy that lands: "Ubuntu is a little Linux workshop we install inside your Windows PC. Claude prefers to work in that workshop — so we build it once, then forget it's there."

Don't dwell on what WSL/Linux technically are. They just need the map: start in PowerShell, end up in Ubuntu, run Claude. Point at the diagram.

This is hurdle #1 — the very first click. Go slow. The most common miss is not choosing “Run as administrator.” Call it out, and check everyone got (and clicked Yes on) the popup.

Reassure: "A command window looks intimidating; it's just a box that waits for you to type. You can't hurt anything by opening it."

This is the fiddliest slide of the day — go slow, do it live, wait for everyone. Two things people trip on: (1) forgetting Run as administrator, and (2) panicking at the invisible password. Call both out before they happen.

Have them write their Ubuntu username + password somewhere safe now — they'll rarely need the password, but they will need it eventually (it's the "sudo" password).

They're each making their own account at claude.ai. The thing that bites people: the free plan doesn't include Claude Code. Confirm with the room how plans/billing are handled at Fibernetics before anyone puts in a card.

Have them use their work email so the accounts are easy to manage later.

"curl … | bash just means: fetch this official setup script and run it." Demystify the scary line. Do it live — it's quick and satisfying.

The home-folder tip matters for WSL: working in ~ (the Linux side) is much faster than /mnt/c (the Windows drive). Don't over-explain — just tell them to stay in ~.

This is the big "I did it!" moment — pause and celebrate it. Everyone types claude together.

The paste-a-code step is the one real WSL login gotcha — warn them so it doesn't feel like a failure. After the first login, it's remembered.

Great first thing to type together: "What files are in this folder?" — zero risk, and it proves Claude can already see their stuff.

This is one of Zoe's core lessons — repeat it: "Folders are your friends." A messy Desktop with 400 files makes Claude slower and less accurate; a clean task folder makes it sharp.

Tell them: "Before starting anything, make a folder for it. It takes five seconds and saves you every time."

Live-demo each one. Have them type along. The mental model: the terminal is a "you are here" pin, and cd walks you through folders like double-clicking, ls is "look around."

Reassure: getting lost is impossible — cd with nothing always returns home.

Key reframe: these commands are good to recognise, but the whole point of Claude Code is you can ask in English instead. Teach them so the screen isn't foreign — not because they must memorise them.

Give the rm warning real weight: it doesn't go to Trash. When in doubt, drag to Trash in Finder, or ask Claude and review first.

This is the official Anthropic workflow, simplified. Drill it — it prevents the #1 failure (Claude confidently doing the wrong thing because nobody explored or planned first).

Caveat to mention: for a truly tiny ask ("fix this typo"), skip planning. Planning is for anything touching several files or unfamiliar ground.

Read the two examples aloud back to back — the contrast sells itself. "Same task. One gets a shrug, one gets exactly what you pictured."

The @ tip is a big quality-of-life win — demo it live so they see the file-picker pop up.

These are on the printed cheat sheet too. Tell them: "You don't need to be clever — you need to be clear. Steal these until your own style comes naturally."

Encourage them to keep a personal note of prompts that worked well — or better, drop them into their CLAUDE.md so Claude just knows.

This slide is where hesitant people relax for good. Hammer: "You are always the approver. It cannot go rogue on your files."

Model good behaviour: never blindly click approve. Read what it wants to do. It's fast, and it builds the review habit that keeps them safe.

This calibrates trust so people neither over-trust (ship errors) nor under-trust (never adopt it). The intern analogy lands well — capable, eager, occasionally wrong, always worth reviewing.

Give a concrete tell: "If it quotes a specific number, date, or policy, that's your cue to verify against the real source. For tone and drafting, the stakes are lower."

Frame plan mode as the "measure twice, cut once" button. It's the antidote to Claude enthusiastically doing the wrong big thing.

Show the Shift+Tab cycle live and point at the mode indicator so they learn to read it. Tell them to ignore the more advanced modes for now.

This is Zoe's signature lesson — give it weight. The principle: an AI's quality quietly degrades as its conversation gets long and cluttered, well before it "runs out of room."

Analogy: "It's like a desk. Start clean and you fly. Bury it in forty unrelated papers and you slow right down. /clear is wiping the desk."

Bonus point they'll love: shorter sessions also cost the company less, because every message re-sends the whole conversation.

Clarify the difference plainly: /clear = forget everything and start over (between tasks). /compact = keep going but tidy up (mid-task). /context = how full am I?

On the numbers: our setup runs an extra-large memory, so 200k/400k are healthy checkpoints, not hard limits. The habit matters more than the exact number — when it feels long, save and clear.

Reassure: "/clear never deletes your files. It only clears the conversation."

Tie the bow on the sprint lesson: they don't need to memorise numbers — they can outsource the reminder to Claude itself via a CLAUDE.md note (which we cover next).

If you have your own CLAUDE.md handy, show the real line you use. Seeing it in your live config makes it concrete.

Analogy: "CLAUDE.md is the onboarding document you'd hand a new assistant — write it once, and every future 'day one' is already done."

Warn about the one trap: keep it short and current. A bloated or outdated CLAUDE.md makes Claude ignore it. Prune ruthlessly.

Use /memory to open and edit these files from inside Claude.

These come straight from Zoe's cheat sheet, tidied. Read each in one breath — the goal is "you'll hear these words; now they're not scary," not deep understanding.

Tell them: you don't need any of these to start. They're the vocabulary of the next level.

Two gentle corrections from the cheat sheet, framed as "close, let's sharpen it" — never as "you were wrong":

Brew isn't an operating platform — it's an installer for the terminal. GitHub isn't "the cloud" — it's version-controlled storage for projects (it happens to live in the cloud).

Skipped AJAX from the sheet on purpose — it's a web-developer term this group won't need. Mention it exists if asked; don't spend time on it.

Purpose of this slide is aspiration, not instruction. Plant the seed: "Once the basics feel easy, this is where it gets genuinely powerful."

Concrete hook for our team: a "monthly Google-review report" skill so it comes out identical every month with one command.

Keep it inspirational and brief. The takeaway: "the tool grows with you — there's always a next level, and none of it is required to be useful today."

If asked how integrations get added: that's an IT/Zoe task (an MCP server), not something they configure alone at first.

Make this personal to each trainee's actual role — swap in the tasks they do. The goal is every person leaving with one real job they can't wait to try.

Reinforce our #1 quality bar: drafts must read warm and human, never templated — and we always review before anything goes out.

This is the inspiration beat — spend a moment here. Click into the two live ones so they see them move (drag the forecast sliders live; it's mesmerising).

The message: "None of this needed a developer. It needed someone who learned to direct the tool — which is exactly what you're doing today." Then pivot straight into 'now it's your turn' with the exercises.

Honest framing on speed: built fast by one person over a short span — don't quote exact hours unless you know them. The point is scale of output vs. effort, not a stopwatch.

Do this in lockstep — everyone on the same step before moving on. Walk the room. The magic moment is step 4: they asked in English and a real file appeared. Let them sit in that.

If someone's stuck, it's almost always: wrong folder (ls to check) or not logged in (/login).

Now they fly solo (with you circulating). The learning objective isn't the output — it's the iteration loop and remembering to /clear between the two tasks.

Watch for the vending-machine reflex — people accepting the first draft. Nudge them: "Now tell it what to fix."

This is the bridge from "training" to "using it for the job." Assign it as homework if you're out of time. Keep stakes low — nothing customer-facing that isn't reviewed.

Ask each person to name their task out loud before they start, so you can catch anything too ambitious or too risky for a first solo run.

This slide is about self-sufficiency — it's what stops a small hiccup from becoming "I give up." Tell them the two-thing rule out loud: wrong folder? / too long?

Normalise getting stuck: "Everyone hits these, including me. Getting unstuck is a two-second habit, not a crisis." Point them to the same list on the cheat sheet.

This is the fridge-magnet slide. The one to circle: if you've corrected it twice and it's still wrong, stop — /clear and rewrite your request with what you just learned. A clean start beats a polluted argument every time.

Don't drill these — just show them once and point out they're on the printed cheat sheet. Esc (stop) and @ (point at a file) are the two they'll use daily; highlight those.

Point them to one next step, not all four — decision paralysis kills follow-through. For this group, "Claude Code 101" is the single recommendation; the rest are optional depth.

Set the expectation of an ongoing cadence — a weekly check-in beats a one-off training every time.

Land the practical close: "You're leaving with three things — the skill, these slides, and a one-page cheat sheet. Download it now so it's on your machine."

Have everyone actually click Download here in the room, and print one, so the very last thing they do is a small success. Then move to the final slide.

Land the plane on confidence. Recap the three anchors on screen. Then open the floor — and capture any recurring questions to fold into the CLAUDE.md or the next session.

End with a concrete next action: everyone books 20 minutes this week to do Exercise 3 on a real task.