T0 · How we teach Praxis
Read this before you run any Praxis session, and come back to it before each one. The decks and teaching notes tell you what to cover. This page is about how we run the room: who does the talking, when you stop, what you show live and which stories you tell. It's the same method in every session, so a group that has had three trainers still feels like it has had one.
How to use these notes
- There's no deck for T0. It's the method you bring to every other deck, starting with T1, the discovery session.
- Part 2, the map, is the one to know by heart. Every feature in the course comes back to it.
- Parts 3 to 5 are the three moves you make in every session: hand it back, say it out loud, run it live. Parts 6 and 7 are about timing and reading the group.
- The stories in part 9 are drafts marked Draft until Daniel has checked them. Tell them in your own words. A story you've lived yourself is always better, so add yours.
- Part 10 is the debrief you do after every session, on your own or with the trainer who watched you.
- Your assignment: take the teaching notes for one core deck (01 Claude 101 is a good start) and mark three places to hand the concept back to a card, one brief to say out loud and one thing to run live. Then run one of those moments with a practice group and write half a page using the debrief questions in part 10. Your tutor marks it within 48 hours against the rubric in T9.
You're briefing a new hire
Everything in Praxis gets easier to explain if the group thinks of AI as someone they've just taken on: a new hire, a temp or a subcontractor. Everyone in the room has handed work to another person. They know you have to explain the job, give them what they need to read, let them into the right systems and check what comes back before it goes to a client. That's exactly what working well with Claude looks like.
The frame also answers the question people don't ask out loud: "whose fault is it when the output is bad?" If a new hire gets it wrong on day one, you look at your briefing first. Same here.
"For the rest of the programme, think of AI as someone you've just hired. Very quick, has read almost everything, knows nothing about your company and forgets the conversation the moment it ends. Your job is to brief them well and check their work. Most of what we teach you is how to do those two things."
Set this up in the first session and then keep coming back to it. By session three the group should be using the frame themselves ("so that's like giving them the login"). When they do, say so out loud. It means it's landed.
Every feature is something you'd give a new hire
Each time you introduce a feature, place it on this map before you explain how it works. The group then has somewhere to put it, and they can work out the details from what they already know about managing people.
| In the course | For a new hire | Ask the group |
|---|---|---|
| The prompt | Explaining the task on their first morning | "What would you say to them before they start?" |
| Context, files, Projects | The briefing pack and the shared folder | "What would you give them to read first?" |
| Context window | How much they can keep in their head in one sitting | "When would you tell them to write it down and start again tomorrow?" |
| Skills | The written procedure for a job that comes back every week | "What do you find yourself explaining every single time?" |
| Connectors | Logins and keys to your systems | "Which systems would you let them into? Read only, or can they change things?" |
| Subagents | Them bringing in their own helpers for part of the job | "Which bit would you be happy for them to pass on?" |
| Checking the output | Reviewing their work before it goes to a client | "How would you know it's right without doing it again yourself?" |
The map is a way in. It isn't exact. A new hire remembers yesterday and Claude doesn't, unless you give it memory or a Project. When someone pushes on the map ("but a person would remember that"), that's a good question. Answer it: the gap between the person and the tool is often the thing worth teaching.
Trainers who explain the feature first and add the map at the end as a summary. Do it the other way round. The map goes first, the detail second.
Hand it back to their card
Every participant leaves T1 with a Use Case Card: one task of their own. From then on, every time a new idea goes on screen, stop and ask someone to explain it using their card. What does a skill mean for their task? How would they start writing one? How is it different from a Project or a connector?
When you explain the slide yourself, the group listens (or doesn't, and you can't tell). When a participant explains it in their own words, three things happen. Everyone stays alert because they could be next. The person talking has to process it the way a teacher does, which is how it sticks. And the others start to disagree, which is where the real learning is. Then you correct them and fill in what's missing.
- "Sophie, your card is the weekly client report. What would a skill be for that? What would you put in it?"
- "Who has a card where a skill wouldn't help at all? Why not?"
- "Marc, explain to Sophie how that's different from putting the files in a Project."
(names are examples. Use the names on the cards in front of you)
Keep the cards visible: on the table, on a shared board or as a list of tasks and names on your second screen. Aim for at least one hand-back for every new idea. Start with people who are confident, and bring in the quiet ones on a smaller question ("yes or no, would a skill help yours?").
A group that goes quiet during the slides. It usually means they've stopped processing and are waiting for the practical bit. That's your signal to hand back sooner. Don't read silence as understanding.
Say the brief out loud
People think they know how to explain their task until they have to do it out loud. A short role play shows the gaps faster than any slide. One person briefs, the group plays the new hire and asks the questions a new hire would ask. Everything they ask is something that belongs in the prompt, the Project or the skill.
"You've just hired an assistant to help with the task on your card. It's their first morning. Tell them what to do. Actually say the words, as if they're sitting next to you."
Then to the group: "You're the new hire. What don't you know yet?"
Write the new hire's questions up as they come. At the end, sort them with the group: which go in the prompt, which are files to share, which are rules for a skill, which need a connector. That list is the start of their brief, and it ties the theory to their own task in a few minutes.
People who describe the task ("I'd tell them about the report") instead of saying the words. Stop them kindly and ask for the actual first sentence. The gap between the two is the whole lesson.
Run it live and stay on the screen
When you type a prompt and then jump to a finished result, the group learns what the output looks like. When you type the prompt, set it going and stay on that screen, they learn how long it actually takes, what Claude does while it works and when it goes off track. That sets their expectations for their own work, and it's the part people can't get from a video.
Use both. Cutting to a result you prepared earlier is fine for long jobs. For at least one task per session, let it run in front of them.
- Kick off
- A real task from someone's card, or the session's running example. Say the prompt out loud as you type it.
- Expect
- Say roughly how long it will take before you press enter ("this usually takes about two minutes").
- While it runs
- Narrate what it's doing (reading files, searching, drafting). Ask the group to predict the result. Ask what they'd check first when it lands.
- When it lands
- Check it together against the card's idea of success. Find one thing to fix.
If it fails live, stay with it. A task that stalls, runs out of room or gets something wrong teaches more than one that works. Say what happened and what you'd change in the brief.
One sentence, then a card
The slides carry more than you need to say. Pick the one sentence each slide exists for, say it, place it on the map and get to a card within a couple of minutes. The detail comes out when you correct what participants say, and it lands better there because it's attached to their task.
"A skill is the written procedure for a job that keeps coming back, so you don't explain it every time. Julie, what's the bit of your task you explain every time?"
Before the session, go through the deck and write the one sentence for each slide in the margin of your notes. If you can't find it, that slide is a candidate to skip.
Yourself reading the slide out. If you catch yourself doing it, stop and ask a question instead.
Two speeds of group
The three moves are the same for every group. How hard you push them depends on who's in the room.
- New or quiet
- Smaller questions, more often. Let people talk in pairs for a minute before anyone speaks to the room. Start hand-backs with yes or no questions. Run more of the live work yourself.
- Fast or experienced
- Ask them to share their screens and show their working. Use the card to probe deeper ("what would go wrong if it had write access?"). Push them to do the thinking their task needs, and don't do it for them. More role play, and let the group challenge each other before you step in.
A group can change speed during the programme, or even during a session. The quiet group from session two is often the one sharing screens by session five. Move them along with it.
Videos and recorded demos
Short edited sequences with a voiceover work well, and making them with Claude is itself worth showing: the group sees how quickly you can produce one. Use them for things that take too long to run live or that need a clean example.
A video is something to watch. It doesn't replace the moves in parts 3 to 5. After each one, hand it back: "which bit of that would you use for your card?"
Keep them under three minutes. If you made it with Claude, say so and say roughly how long it took.
The story bank
People remember a story long after they've forgotten the slide. There's one story here for each line of the map. Tell them in your own words, at the moment each one is marked for. These are drafted from our blog and client work and marked Draft until Daniel has checked them.
A lot of people try AI once, get generic slop back and write the whole thing off. Fair enough, the first go often is rubbish. But generic results usually mean the steering was off. If a new hire handed you something that bland on their first morning, you'd look at what you told them first.
Tell it when someone says "I tried it and it was useless". From the blog post "It's never just one reason".
Brian Madden keeps his whole working life in a folder that AI can read: his notes, ideas, plans and current thinking, updated daily. He publishes part of it so anyone's AI can draw on it. The lesson we took from it: the gap between "AI gives good answers" and "AI does my actual work" is almost always what it's been given to read, and much less the model.
Tell it when you introduce Projects and files. From "Making Knowledge Machine-Readable".
Most AI training leaves people knowing what a context window is without ever feeling it run out on a real task. Coding tools show you: you watch it fill up, and you hit the same wall engineers hit. The new hire version: after a long day of instructions, the first things you said are the ones they've half forgotten. Write it down, start fresh.
Tell it when a long chat starts to drift. From "The Podcast That Clarified Why Praxis Exists". This one needs a story of your own: a real long conversation that went off track.
In our September webinar we wrote a skill by hand to handle customer complaints and ran it live. Claude found the two complaints, ignored the stock question in the third email, opened the tickets with the right order numbers and drafted two replies. The tone was very warm and a bit too generous: it offered 20% off the next order. That's exactly what you fix in the skill, the way you'd correct a new hire's procedure after the first week.
Tell it when you introduce skills. From the webinar recap "Start the new season with Claude".
A client's operations team was copying data into the chat, getting good advice and then carrying it back into SharePoint by hand. Like a new hire with no logins who has to walk every piece of paper to someone else's desk. Once we gave Claude a connector to their SharePoint and Power Automate, listing their lists, adding a column and finding the last five failed runs of a flow took minutes. Through the usual screens it took most of an afternoon.
Tell it when you introduce connectors. From "How We Gave Claude Direct Access to a Client's SharePoint".
Most of a small team's AI work is sorting: which emails need me today, is this invoice complete, is this a lead or spam. Sending all of that to the biggest model is like hiring a lawyer to open the post. A good new hire passes the sorting to someone suited to it and keeps the judgement for themselves.
Tell it when you introduce subagents or choosing a model. From "The AI model that can't write a word".
Two young hikers asked an AI to plan their first mountain trip. It drew them a map. They got lost, and the ranger who found them said nothing on it was right: the lake was in the wrong valley. The map never said it wasn't sure. It just drew a line. A correct answer and an invented one read the same, so you decide in advance where the checks go.
Tell it when you introduce checking the output or the scorecard. From "The map never said it wasn't sure".
In the same webinar, after two skills, some searches and dozens of actions, the live demo hit its usage limit and stopped. Frustrating at the time. It's also exactly what will happen to the group one day, and they saw it happen and saw what we did about it.
Tell it when something fails in front of the group. From the webinar recap.
The debrief
It's hard to tell during the slides what's landing and what isn't. The debrief is where you find out. Do it the same day, on your own or with the trainer who watched you, and write down one thing to change for next time.
- Where did the group go quiet? What was on screen at the time?
- How many times did I hand an idea back to someone's card? Who never got asked?
- Did anyone say a brief out loud? What did the new hire's questions show?
- Did I run at least one task live and stay on the screen? Did they get a sense of how long it took?
- Which slide did I explain in detail that I could have said in one sentence?
- Which story did I tell, and did it land?
- What's different about the next group, and how does that change what I do?
Start with what worked, and be specific about the moment. Then pick the one or two moments where the group could have done more of the talking, and name the move you'd use there next time (a hand-back, a brief out loud, a live run). Finish with what that means for their next group. Keep it to things they can try in the next session.
Adding this to a deck's notes
The teaching notes for each deck will carry the three moves at the slides where they belong, so trainers don't have to work them out on the day. There are three block types for that, alongside the ones the notes already use (idea, say, ask, watch, cue, key). The markup follows the same pattern, and the CSS is at the top of this page.
block--card- "Back to your card": the hand-back questions for this slide, using the Use Case Cards.
block--brief- "Brief it like a new hire": where this slide sits on the map, and a role-play prompt.
block--live- "Run it live": what to kick off, how long it takes, what to say while it runs.
<div class="block block--card"> <div class="block-head"><span class="block-label">Back to your card</span></div> <ul><li>"..."</li></ul> </div>
Put at least one of the three on every slide that introduces something new. Decks 01, 03, 07, 08, 09 and 17 already have them at the slides that cover prompts, Projects, skills, connectors, subagents and where Claude keeps what it knows.