Claude Code in Action: teaching notes

"Fourteen ideas, one screen each. Last time we talked about what this thing is. Today you watch it actually do the work: installed, pointed at real files, making changes you review, then locked down so the things that must happen always happen. I'll show each piece, then stop and ask where it fits your week."

"Here's the whole thing on one screen. We see what the agent is, we get it running, we drive it day to day (making changes, controlling what it sees, connecting it out), then we make the must-haves guaranteed with hooks, and finish with the SDK. If a word lands and you've no idea where it sits, this slide is the map back."

"There's a spectrum here. At one end, autocomplete: it finishes your line. In the middle, a chat assistant: it answers, and you carry the answer across yourself. At the far end is Claude Code: it reads your files, edits across them, runs the commands, and decides what to do next. Same intelligence you know from the browser, but now it has hands." (Pairs with framings.md, the folder is the memory: the work moves out of a chat you lose and into a place that persists.)

"This is what a session looks like, top to bottom. You ask in plain English. It finds the files that matter, edits across them, runs them to check its own work, and shows you the result. You look, you refine, it goes round again. The demo uses a little sample app, but that's just so everyone has the same thing to point at. Your own folder works exactly the same." (patterns.md, the 80/20 expectation: set it here, before any live run, "you'll get ninety percent of the way; you finish the last ten, and even eighty percent is an enormous cut".)

"Installing is one line, and which line depends only on your machine: Mac, Linux, Windows. Then you type claude, pick a colour theme, sign in with the account you already have. The fastest way through it, honestly, is to ask Claude itself to walk you through the install. That's how most people get over the line." (framings.md, ask Claude to install Claude: "I'm going to be using Claude Code on my command line to control one of my folders. How do I set that up?")

"The course gives you a little app to play with so nobody starts from a blank screen. You download it, run one setup command, and it's live. But don't fixate on the sample. The point is you can point Claude Code at any folder of your own work and start there instead. That folder is the project." (framings.md, the folder is the memory: "you've now put it in your files; the folder is the memory".)

"Claude knows exactly what's in front of it and nothing more. So before you ask, you put the right things in front of it: point at a file with the @ sign, paste in an error or a screenshot, keep your standing rules in a file it reads every time, and let it search the folder when it needs to. The skill is being specific. Vague prompts cost you, because it goes wandering to fill the gap." (framings.md, context window: the browser chat forgets the beginning once it runs long; here the memory is bounded by your disk, and the rules file keeps working across every file you drop in.)

"Here's the part people worry about, and it's the part you have the most control over. You describe the change. It makes the edits and shows you a diff: a side-by-side of exactly what it changed, nothing hidden. You approve, or you correct it and it goes again. Nothing gets locked in until you say so. You're never handing it the keys; you're reviewing every change before it lands." (objections.md, permission: confirm-each- step first, you always check the end, switch to faster modes once the pattern is familiar.)

"Think of its working memory as a desk. Every file it reads, every command it runs, lands on the desk, and the desk has an edge. When you start something unrelated, /clear wipes it clean. When you're mid-task and it's running long, /compact tidies up but keeps the thread. And /context shows you what's taking the space. If answers start drifting, that's usually a full desk." (framings.md, context window: here the memory is bounded by your disk, not a chat that forgets the beginning.)

"Anything you find yourself typing over and over (a review checklist, a release routine, the way you want a report formatted), you write down once as a command. After that you just type a slash and its name, and the whole long prompt expands. Put it in the shared folder and everyone on the team has the same shortcut, the same way, every time." (framings.md, skill file as institutional memory: "those rules lived in your senior person's head and walked out the door at six o'clock; this pulls them onto disk so a new joiner does the work the same way on day one". Adapt the role to the room.)

"Your real context doesn't all live in one folder. It's in your email, your project tracker, your databases. MCP is the one standard that plugs those in, so Claude Code can reach your actual data instead of starting cold. One thing to know: each connection costs a little memory up front whether you use it or not, so you turn off what you don't need." (objections.md, IT/compliance: it sees only what you can see; connecting your email doesn't expose anyone else's, and you can revoke it.)

"Two things on this slide. The top half is you on your own machine: once a change is right, one flow commits it, pushes it, and opens it for review. The bottom half is where it gets interesting for a team: you can tag Claude on a piece of work, and it goes off and does it on a server, then comes back with the result for someone to review. That's the same agent you've been driving, now working while you're not watching." (Adapt to their world: this is the colleague who picks up the ticket, does the first pass, and leaves it ready for your sign-off.)

"Everything else this session is something you ask for, and usually get. A hook is something that always happens, no asking, no exceptions. The reason it's reliable is that it's run by the machinery around Claude, not by Claude deciding to remember. Format every file. Log every action for compliance. Block a dangerous step before it runs. The rule of thumb: if it has to happen every single time without fail, it doesn't belong in a prompt, it belongs in a hook." (For these learners the headline is the guarantee, not the syntax: some rules are too important to leave to "usually".)

"A hook is three simple decisions. When does it fire, for instance, just before a tool runs. What does it apply to. And what command should run. The powerful case is the 'before' hook: it can look at what's about to happen and stop it. So a dangerous delete, or a change to something protected, gets caught before it happens, not cleaned up afterwards. You're moving from 'we'll review it after' to 'it can't happen in the first place'." (Keep it conceptual; this concept does not vary much by domain; see the shared example below.)

"Two real-world snags. First, sharing: the secure way to write a hook uses the full path to a script, but my full path won't match yours, so the project uses a placeholder that gets filled in automatically when each person sets up. That's how a team shares the same guarantees without hand-editing paths. Second, debugging: a hook gets fed information, and the shape of it changes depending on what triggered it, so the trick is to log it first and look, then write the real rule against what you actually saw." (Concrete, not abstract: this is the "measure twice, cut once" of hooks.)

"Last idea, and it's a horizon, not a homework. Everything you've watched Claude Code do at the terminal can also be wired inside other software, so instead of you sitting and driving it, it runs as a part of a bigger system you build. That's how your one repeatable workflow could eventually run on a schedule, or on every new file, with nobody at the keyboard. You don't need this today; it's where the road goes." (Hold the one term: it's Claude Code, and the SDK is the same agent as a library.)

"If you keep one thing, keep the shape: you watched it act, you learned to drive it day to day, and you learned how to make the things that must happen always happen. The durable version of your task isn't a chat you lose; it's a folder, a set of reusable commands, and a guarantee or two that hold every single time."