The default starting position is no AI at all. Rick Dakan of Ringling College of Art and Design, one of the course's authors, rejects the public embrace-or-reject binary. The course instead gives a framework for deciding whether to opt in, and treats arriving at "no AI" through rigorous analysis and arriving at integration as equally valid acts of AI Fluency.
Five recurring creator concerns are real and deserve answers, not dismissal. They are authenticity anxiety ("if AI touched it, is it still mine?"), dependence and lost skills, settling for good enough, slop fatigue and guilt by association, and "what I do is worthless." Dakan's own position on the last is that the creative role is changing rather than disappearing, and that a flood of generated content makes real craft with intent rarer and more legible.
AI's pull toward the median makes your own standards essential. AI readily produces adequate, median output but struggles with work that is unique or excellent by a creator's standards. Without articulated standards, good-enough output becomes the path of least resistance and the work drifts toward the generic, sometimes losing its distinct voice.
The course's work sits upstream of prompting. It deliberately teaches no specific tools, interfaces or prompting techniques, and points to other Anthropic resources for those. By the time a prompt is written, the key decisions (what you are making, your standards, whether AI fits the task at all) have already been made.
There is no single right answer, only defensible decisions. Dakan says two illustrators with similar work and audiences may legitimately land in different places. The framework does not remove the work of deciding; it structures it, and is meant to stay useful as tools and the creative landscape keep changing.
Teaching AI Fluency: 07-Applying discipline expertise to AI Fluency
Making a field's tacit knowledge explicit comes first, without AI. The lesson argues you can't partner well with AI in a field until you can say what quality looks like, how experts communicate, which problems matter and what standards apply. Its closing exercise drops the AI entirely and has teachers work through the 4Ds with colleagues to build a shared document.
Discernment starts with precise quality criteria, exemplars and failures. The lesson begins with Discernment, calling it among the most important human competencies now that AI produces endless content. Its advice: replace vague words like "well-argued" with detailed rubrics, mark up outstanding published work with students, and dissect flawed examples (failed arguments, buggy code, designs that don't scale) to show exactly where they break down.
Description comes from mapping the field's products, thinking and norms. Don't just say "lab reports". Specify the sections and why the methods come before the results. The lesson also suggests tracing how experts think, such as how a historian evaluates sources, with practitioner interviews and flowcharts. Finally, name the observable behaviours of the discipline, such as scientists' protocols for skepticism, replication and peer review.
Delegation means breaking tasks down to see where AI fits. The lesson takes a literature review apart into finding sources, judging relevance, synthesising arguments and writing the narrative, then asks which parts can be automated. It suggests mapping what AI could automate (data cleaning, first drafts), augment (hypothesis generation, literature synthesis) or do as an agent (monitoring experiments, early feedback on student work). Then build decision trees through case studies.
Diligence means codifying the field's own ethics, disclosure and accountability. Go beyond general academic integrity. The lesson's examples are privacy when AI analyses patient data and client confidentiality in AI-assisted legal research. It suggests disclosure templates (how to cite AI in a research paper versus a creative portfolio versus a business report) and co-created classroom policies and honour codes. The payoff it claims is that students who know their field's quality, methods and ethics can direct any collaborator, human or AI.
Teaching AI Fluency: 06-AI's impact and your discipline
AI fluency amplifies disciplinary expertise rather than replacing it. The lesson frames graduates' futures around three questions. What gets automated in their field? Where does human-AI partnership add the most value? When AI works on its own, how do they manage it and stay accountable for what it does?
Disruption varies across curriculum, pedagogy and assessment, and expertise sorts it. The lesson's examples are a stable curriculum with transformed assessment, or evolving pedagogy around a constant core. Some disruptions are opportunities and others are problems. Telling which is which takes three kinds of expertise teachers already have: disciplinary (the field's values and methods), pedagogical (where students struggle and break through) and assessment (recognising real understanding).
The fundamentals stay, but each one needs a discipline-specific defence. The lesson expects students to ask "why learn research methods when AI can search for me?" Its advice is to work with colleagues to map what AI can automate in the field and which concepts gain or lose importance. Directing AI agents effectively is one of the skills to teach.
Some AI use enhances learning and some only shortcuts it. The lesson credits AI with making tutoring at scale, interactive simulations and immediate feedback possible. It asks each discipline to work out where AI helps or hinders learning, and which teaching approaches to adopt or actively discourage.
Assessment is the biggest disruption AI creates for educators. "When students can generate essays in seconds, what are we actually assessing?" The lesson calls for authentic assessment of both AI-assisted and human-only work, assignments AI can't shortcut, and credit for process and growth. Since students will likely use AI regardless, it suggests possibly shifting to assessing critical thinking and skill working with AI. It concedes this is "easier said than done" and should be worked out with students, colleagues and institutions.
Teaching AI Fluency: 05-Designing assignments for AI Fluency
Design assignments around authenticity, iteration and pedagogical transparency. The lesson says assignments should be genuine problems where AI actually adds value, not artificial exercises. They should build in chances to refine and try again, because single-shot work misses how fluent collaboration actually goes. Students should also be told plainly that the collaboration process and their reflections are graded, not just the output.
Outcome-based assignments grade products but expose collaboration skills. The lesson's formats: turn a mediocre AI output into an excellent one, and run the same task on several AI systems or modes (it names extended thinking and image-to-image) and compare the results. Constraint challenges set format, length, style and audience, and students submit the prompts along with the product; adding ethical, legal or professional constraints brings in creation diligence. In peer product review, students swap work and critique it against each other's stated goals.
Process-based assignments make private, fleeting AI work visible. The lesson's options are annotated chat logs that mark turning points and recoveries, and narrated screen or audio recordings made while working. Students can also build their own playbook of strategies by task type, or debrief a chat log with an AI, a peer or both, then compare the insights.
Reflection assignments need variety to avoid reflection fatigue. The options are guided questions that invite honest complaints as well as praise, learning journals that self-assess 4D progress with evidence in several formats, and case scenarios such as "your new boss wants you to use AI for hiring decisions." If there is room for only one, the lesson recommends a personal policy statement on the student's own values and methods.
Plan for the extra volume these assignments generate. The lesson's fixes: granular deliverable-based rubrics that can be checked quickly, and self and peer review that condense long AI outputs. It also suggests lightning-round conferences, where five minutes of discussion can replace extensive written comments. Instead of reading every chat log in full, have students flag the key moments.
Combine outcome, process and reflection assessment for a full picture. The lesson's aim is to tell a student who has found some clever prompts from one building real collaborative skill. Outcome-based assessment judges what was produced. Process-based assessment examines iteration, recovery from failed attempts and methodological sophistication. Reflection-based assessment tests whether students can explain why their strategies worked or failed.
Delegation and Description need evidence from plans and chat logs. For Delegation, the lesson asks whether the plan made sense, the goals were realistic and the tool fit the job. The evidence is annotated chat logs of the decision process plus students explaining the alternatives they weighed. For Description, it assesses prompt quality and how prompts evolved from first to final version. Logs, read against a rubric, should show refinement, documented failures, pivots and shared context built up over time.
Discernment and Diligence need evidence of judgment and responsibility. For Discernment, the lesson suggests annotated AI outputs and decision logs recording what was kept, modified or discarded. It also looks for inline evaluation comments and caught errors in chat logs. For Diligence, it assesses diligence statements, attribution, fact-checking, data handling visible in the logs, and reflection on the ethical dilemmas students met.
One essay assignment can be assessed from all three angles. In the lesson's example, students write an essay on Gen AI's impact on society and submit four things: the essay, a link to their AI interactions, a diligence statement and a learning journal. The essay and statement are read for human oversight and transparent disclosure. The interaction log is read for shared context and course correction. The journal is read for lessons learned.
Assess observable artifacts, and make assessment a learning opportunity. The lesson's principles are to rely on concrete actions and artifacts rather than assumptions about understanding, and to match assessment methods to each competency. Above all, assessment should help students recognise their own growth as AI collaborators.
Teaching AI Fluency: 03-The Description-Discernment loop
Teach building shared context, not prompt tricks. The lesson says students arrive thinking AI skill means clever hacks. It wants them to stop treating AI as an input-output command line and build a "cognitive environment" instead: shared vocabulary that evolves, defined goals and methods, set patterns of interaction, and ways to build on earlier exchanges. It argues no single prompt, however well engineered, gets there, and that this skill lasts longer than copied prompts.
Product iteration clarifies the student's own goal as well. Product, Process and Performance are three lenses on one collaboration. In the lesson's example, "help me write about social media and teenagers" gives a generic response. Through Discernment it becomes a request to analyse how teens present different versions of themselves across platforms, written so readers grasp the psychological toll. The lesson calls this the move from automation to augmentation.
Process descriptions grow from vague to explicit methods. In the lesson's hypothetical, "analyze this step-by-step" becomes a set routine: author's context first, then content and notable omissions, then several interpretations before any conclusion. Process discernment asks whether the method finds insights the student would miss alone. In the example, the student learns their AI is good at cross-document patterns but needs guidance on emotional and cultural context.
Performance tunes the working relationship, and Discernment keeps revising it. The lesson's sample instructions include asking the AI to act as "a kind but rigorous skeptic," to use music analogies, or to keep some humour in creative tasks. The student later revises the first one: save the skepticism until after the initial ideas have formed.
Assignments must span many interactions within and across chats. The lesson says single-prompt exercises can't build cognitive environments. Multi-chat work also teaches students which context carries over and which must be re-established. Teachers should show their own AI collaborations and have students record how the collaboration evolved, not just the outputs. The signs to look for are shorthand shared language and a shift from rigid "Do X then Do Y" commands to exploratory exchanges.
Teaching AI Fluency: 02-The Delegation-Diligence loop
This loop asks whether, when and how to use AI at all. The lesson frames it as moving students from "how do I use AI?" to "how do I make good decisions about AI?" That includes choosing among human-only work, AI-human collaboration and AI automation. The loop is built from six sub-competencies: problem awareness, platform awareness and task delegation on the Delegation side, and creation, transparency and deployment diligence on the Diligence side.
Delegation choices immediately raise Diligence questions. In the lesson's example, a student writing a policy brief on digital privacy compares AI systems and hands the AI the research synthesis but keeps the policy recommendations. That raises three questions: can stakeholder information be shared with the system, how will AI's role be acknowledged, and what fact-checking secures the data. The lesson gives students a set of questions for each step, from objectives and resources through to ethics, disclosure and verification.
Diligence obligations also reshape Delegation, and the lesson says they improve it. A student on a community project who feels responsible for representing voices accurately lets AI analyse interview patterns but keeps the narrative interpretation for themselves. A student who documents AI contributions in detail can delegate more with confidence, because the boundaries are set. The lesson's claim is that "accountability enhances agency and creativity."
Teach the loop through scenarios worked in both directions. The lesson suggests giving students a project brief and having them start from Delegation, then push into Diligence. Then flip it, starting from a constraint such as "your school requires all AI use to be clearly labeled," and compare what each direction revealed. The exercise has the teacher build such a scenario from their own discipline, with decision points and a plan for how students record their thinking.
Clear rationales show students are getting the loop. The lesson's signs of success: students can say why their approach fits their goals and values, not just what they did. They treat ethical constraints as "creative catalysts" rather than limits, and they expand their AI use because they know what they are accountable for.
Teaching AI Fluency: 01-Welcome & approaches to teaching AI Fluency
The framework both describes AI work and prescribes better practice. The lesson says it maps what people actually do with AI (the decisions, communication, evaluation and responsibility) and also shows what they should do. Students need both halves: how AI interactions work, and how to make them work better.
The linear approach suits beginners. It runs the 4Ds in order: Delegation, Description, Discernment, Diligence. The lesson's example is a four-part assignment: project planning for Delegation, hands-on workshops for Description, evaluating outputs together for Discernment, then ethics discussions and transparency practices for Diligence. Each part builds on the one before.
The non-linear approach treats the 4Ds as an interconnected system. It is meant for students with more AI experience. In the lesson's examples, problems found through Discernment send a student back to Delegation, for instance when evaluating code shows the chosen AI system doesn't suit their programming paradigm. Privacy duties under Diligence reshape Description, so prompts leave out sensitive data. Trouble describing a need exposes goals that were never defined at the Delegation stage. The lesson recommends this approach for case-based learning.
The focused approach spends whole sessions on one competency. It suits workshops and seminars, and the lesson says it avoids the cognitive load of juggling all four Ds at once. One example is three Discernment sessions: product discernment (accuracy and usefulness of output), process discernment (the AI's problem-solving approach) and performance discernment (whether its communication style helps the collaboration).
The two-loops approach is the most conceptually rich. Once students know the basics, the lesson splits the work into two loops. The Delegation-Diligence loop covers strategic and ethical decisions: what to do, how to divide the work, which systems fit your values. The Description-Discernment loop covers moment-to-moment tactical iteration. The lesson says each loop constantly reshapes the other, and that the choice among the four approaches should follow students' readiness, the time available and the learning goals.
Introduction to evals: 04-Evals in production: CI, batch, and drift
An eval keeps running after launch, on edits and live traffic. The lesson argues two things keep changing: the team edits the prompt, which can break answers that were right, and real inputs drift away from the tested ones. Its example is Meridian, a fictional consultancy whose 50-case suite checks a prompt that extracts project ID, schedule status and top risk from monthly reports.
Run a fast smoke eval on every pull request. Meridian runs 10 of its 50 cases, chosen to cover every report type, on Claude Haiku 4.5 in about a minute, against an 88% threshold (nine of ten must pass). The CI workflow runs the eval script, scores the JSON results, comments on the PR and fails the check below the threshold; Meridian uses GitHub Actions, but any CI that can run the script works.
Make the check required, or a red X is only a warning. Merge blocking comes from a branch protection rule, not from the workflow file. In the demo, a PR titled "Simplify extraction prompt" dropped the return-null rule and the quote-the-source rule, scored 80% with two missing-risk cases (r041, r042) naming a risk that wasn't there, and stayed unmergeable until the fix brought it to 100%.
Run the full suite through the Batch API at half price. Since nobody waits on it, the full suite (150 requests: 50 cases on each of Haiku 4.5, Sonnet 5 and Opus 5) goes as one batch; at August 2026 prices one pass cost $0.0468/$0.1301/$0.3432 standard versus $0.0234/$0.0650/$0.1716 batched. Each request needs a unique custom_id such as r041_claude-haiku-4-5 because results return in any order, and request_counts should be read before scoring, since batches expire after 24 hours and expired requests come back with no answer.
Grade a nightly sample of live traffic to catch drift. The suite only knows the reports it was built from, so a new client format can degrade answers while CI stays green. The recommended starting points are sampling 1–5% of traffic, grading it with an LLM judge against a rubric (with occasional human spot-checks of the judge), alerting only when a night falls more than two standard deviations below the trailing baseline, and turning each failure into a new labeled case in the full suite.
Introduction to evals: 03-Iterate the prompt before you upgrade the model
Fix the prompt before paying for a bigger model. A low score doesn't say whether the model or the prompt is to blame, and an upgrade raises the price of every later request, while a prompt edit takes minutes to test. In Meridian's demo (August 2026), Sonnet 5 and Opus 5 scored 50 of 50, while Haiku 4.5 scored 84% against a 90% accuracy floor.
Read the failures and group them by report type and field. Haiku's 8 failures were 3 typical reports on schedule_status and 5 of the 10 missing-risk reports on top_risk, each naming a risk where null was expected. In case r045 it called a routine permit renewal the top risk although the report said "the team does not anticipate any issues"; the cause was a prompt line ending in "or null" that never said when null applies.
Choose from five standard hallucination fixes; Meridian used two. The five are letting the model say "I don't know", quoting before answering, citing back to the document, adding a verification pass, and restricting outside knowledge. Meridian stated when to return null and required a <source> quote ahead of the JSON, which means the code must now parse only the text after the closing </source> tag.
The revised prompt made the cheapest model the best choice. Rerunning the same 50 cases on all three models, Haiku went from 90/100/50% to 100% on typical, multi-project and missing-risk reports. With every model clearing the floor, cost per completed task decided it: $0.0009 for Haiku, $0.0025 for Sonnet 5 and $0.0061 for Opus 5 at August 2026 standard prices.
Check every column and rerun, because results vary between runs. The three schedule_status failures also passed, though no change touched that field, which the lesson attributes to run-to-run variation, so it advises running each setup two or more times and confirming no correct answer turned wrong. Its rule: keep iterating while the score moves, and upgrade only when it stalls below the floor, which signals a missing model capability.
Introduction to evals: 02-Build a minimum viable eval
An eval replaces opinions about models with a number. It has three parts: realistic inputs, an expected answer for each, and a way to grade what each model returns; the lesson likens it to an exam with an answer key, a scoring machine, and a teaching assistant grading essays from a guide.
Use the quickest grader that's reliable and scales. Code-based exact matching goes first, an LLM judge handles answers where different sentences can both be right, and human grading, best quality but slow and costly, is kept for specialized, high-stakes or judgment calls. For Meridian, project_id (e.g. MER-2524) and schedule_status (on_track/at_risk/delayed) are code-graded, as is a null top_risk, while a stated top_risk sentence goes to the judge.
The case set should look like production traffic. The rules are task-specific cases from real reports, automated grading, volume over polish, and edge cases stratified to their production share (if scanned reports are 5% of traffic, make them about 5% of cases); the lesson says 20–50 simple cases is a great start. Meridian used 50 (30 typical, 10 multi-project, 10 missing-risk), with expected answers written by hand before any model runs and kept in golden.json.
Give the judge a rubric, a schema, and an "unknown" option. The judge's prompt holds the report, the answer and a detailed rubric in separate XML tags, but not the expected answer, so differently worded answers aren't penalized. Structured outputs force a verdict of correct, incorrect or unknown plus an explanation; "unknown" keeps the judge from guessing when unsure.
Validate the judge before trusting it on free text. On the 30 missing-risk answers that code could also grade, the judge agreed with code 10/10 for each model, scoring Haiku 4.5 at 5 correct and 5 incorrect, and its explanation for case r045 pinned the error on a prompt that never says what to do when no risk is named. The lesson still advises hand-grading a sample, tightening the rubric where you disagree, and using a different model as judge from the one that wrote the answers.
Measure which model handles your task; don't guess. No published comparison has seen your prompt, so the lesson says to measure accuracy on your own cases first and only then look at cost. Its analogy is buying a ladder: measure the wall, discard ladders that don't reach, buy the cheapest that does.
Set the accuracy floor from what one wrong answer costs. For Meridian, a wrong extraction means a 5-minute manual check and engineers can absorb 5 per month, so 5 of 50 reports gives a 90% floor. If one wrong answer cost $1,000, for example by reaching a client, the floor would be 100% and model price would barely matter.
Score every model on the same cases with the same prompt. A task counts as completed only if all three fields are right, with ID and status matched exactly and the risk sentence compared loosely. On 50 reports, Sonnet 5 and Opus 5 scored 100% while Haiku 4.5 scored 84% (90% typical, 100% multi-project, 50% missing-risk), below the floor.
Compare cost per completed task, taken from usage blocks. Read actual token counts from each response's usage block, because tokenizers differ: per the lesson, Sonnet 5 and Opus 5 produce about 30% more tokens for the same text than Haiku 4.5. At August 2026 rates (per million input/output: Haiku $1/$5, Sonnet 5 $2/$10, Opus 5 $5/$25), run costs were $0.0380, $0.0984 and $0.2323, or $0.0009, $0.0020 and $0.0046 per completed task, since failed calls are still billed.
Pick the cheapest model that clears the floor. For Meridian that is Sonnet 5; Haiku's lower per-task figure doesn't count because it isn't a candidate. The lesson adds that the result is tied to this prompt and these cases, so the eval should be rerun when either changes; that latency isn't measured; and that evals can run on the Batch API at half price, as long as batch and standard rates aren't mixed in one comparison.
Introduction to agent skills: 06-Troubleshooting skills
Start with the validator before debugging anything else.claude plugin validate ~/.claude/skills (personal) or claude plugin validate .claude/skills (project), which needs Claude Code v2.1.233 or later, flags SKILL.md files whose frontmatter doesn't parse. The lesson notes that the video demonstrates a separate verifier installed with uv.
A skill that doesn't trigger almost always has a weak description. Claude matches requests to descriptions semantically, so the fix is to add the trigger phrases people actually use and to test variations such as "help me profile this", "why is this slow?" and "make this faster", adding keywords for any that miss.
Loading failures are structural; check location, file name and debug output. SKILL.md must sit inside a named directory rather than at the skills root, and be named exactly SKILL.md; claude --debug shows loading errors mentioning the skill. For plugins, check /plugin (Installed and Errors tabs), run /reload-plugins after a mid-session install, and keep skills in a skills/ directory at the plugin root, not inside .claude-plugin/.
Wrong or ignored skills usually mean overlapping descriptions or names. Descriptions that are too similar confuse selection and should be made more distinct. A same-named skill at a higher priority level wins every time (an enterprise "code-review" beats a personal one), so renaming is usually easier than going to the admin.
Runtime failures come from dependencies, permissions or path separators. External packages must be installed and should be noted in the description, referenced scripts need chmod +x, and paths should use forward slashes everywhere, including on Windows.
Committing skills to the repo is the simplest way to share. Skills in .claude/skills reach anyone who clones the repo and update on the next pull, which the lesson recommends for team coding standards, project-specific workflows and skills that reference the codebase's structure.
Plugins distribute skills beyond one repo via marketplaces. A plugin project holds a skills directory with one folder and SKILL.md per skill; once published to a marketplace, others can discover and install it. The lesson says this suits skills that aren't too project-specific and are useful beyond the immediate team.
Managed settings deploy mandatory skills organization-wide at top priority. Administrators put skills in .claude/skills/ under the managed settings directory on each machine (e.g. /etc/claude-code/.claude/skills/ on Linux), where they override same-named personal and project skills. Managed settings also restrict plugin sources via strictKnownMarketplaces, with github and url entries shown; the lesson says this route is for what "must" be consistent, such as security and compliance.
Subagents don't inherit skills you've already invoked. A subagent starts with a fresh context unless it's a fork, though it can still find and invoke skills if it has the Skill tool. Built-in agents like Explore and Plan don't preload skills; custom subagents in .claude/agents can list skills in a skills frontmatter field, which load in full at startup, and should keep Skill in any tools list. The lesson notes the /agents wizard shown in the video was removed in Claude Code v2.1.198, and that a newly created .claude/agents directory needs a restart.
Introduction to agent skills: 04-Skills vs. other Claude Code features
CLAUDE.md is always loaded; skills load only when relevant. The lesson puts project-wide standards, constraints like "never modify the database schema", and framework or style preferences in CLAUDE.md, and task-specific procedures, such as a PR review checklist, in skills so they don't clutter every conversation.
Subagents isolate delegated work; skills add knowledge to the current conversation. Subagents fit when you want a separate context, different tool access, or isolation from the main thread; skills fit when Claude's expertise should improve for the task at hand.
Hooks are event-driven, skills are request-driven. Hooks suit operations on every file save, validation before specific tool calls, and automated side effects, while skills supply the knowledge and guidelines that shape how Claude reasons about a request.
Combine the features instead of forcing everything into skills. A typical setup, per the lesson, pairs CLAUDE.md for always-on standards, skills for on-demand expertise, hooks for event-triggered operations, subagents for isolated delegation, and MCP servers for external tools and integrations, which it calls a different category from skills altogether.
Introduction to agent skills: 03-Configuration and multi-file skills
Every frontmatter field is optional, but the description matters most. In Claude Code, name defaults to the directory name and description is the recommended field because Claude matches on it. Uploading to Claude.ai or the Claude API makes both required: name is limited to lowercase letters, numbers and hyphens up to 64 characters, and description to 1,024 characters. model picks the model for the skill.
A good description says what the skill does and when to use it. The lesson's point is that "your job is to help with docs" would leave a person guessing, and Claude too; if a skill doesn't trigger, add keywords that match how requests are actually phrased.
allowed-tools pre-approves tools without restricting Claude to them. Listed tools skip permission prompts for the rest of the turn that invoked the skill, and the grant clears with the next message; other tools such as edits still go through normal permissions. The lesson warns that a bare Bash pre-approves shell commands generally and suggests narrowing it to a pattern like Bash(git status *), and points to disallowed-tools for removing tools while a skill is active.
Use progressive disclosure to keep SKILL.md small. One 2,000-line file wastes context and is hard to maintain, so essentials stay in SKILL.md, kept under about 500 lines, and links point to scripts/, references/ and assets/ with instructions on when to load each. The lesson likens this to keeping a table of contents in context rather than the whole document.
Tell Claude to run scripts rather than read them. A script executes without its contents entering context, so only its output costs tokens. The lesson recommends this for environment validation, consistent data transformations, and operations more reliable as tested code than as generated code.
Introduction to agent skills: 02-Creating your first skill
A skill is a named directory holding a SKILL.md file. The worked example is a personal pr-description skill in ~/.claude/skills/pr-description/. Its frontmatter name identifies the skill, its description ("Use when creating a PR, writing a PR, or…") is the matching criterion, and the body tells Claude to run git diff main...HEAD and write What / Why / Changes sections, so the format comes out the same every time.
Only names and descriptions load until a request matches. Claude compares each request to the skill descriptions by intent, so "explain what this function does" matches a skill described as "explain code with visual diagrams", and then reads the whole SKILL.md. The video's narration says Claude asks for confirmation before loading. The current written lesson says a skill with only name, description and instructions loads without asking (that step was removed in Claude Code v2.1.19), and only skills that pre-approve tools or add hooks may prompt.
Name conflicts resolve enterprise first, then personal, then project. An enterprise "code-review" beats a personal one of the same name, so the lesson advises descriptive names like "frontend-review". The video ranks plugins last; the written lesson says plugin skills are namespaced as /plugin-name:skill-name and load alongside a same-named skill instead.
Edits and deletions take effect without a restart, with one exception. The video says to restart after changes, but the written lesson says Claude Code watches skills directories and picks up edits, new skills and deleted directories in the current session. The exception is a ~/.claude/skills directory created mid-session, which needs /reload-skills after each change.
Skills turn instructions you keep repeating into something written once. A skill is a folder whose SKILL.md carries a name and description in frontmatter and task instructions below, such as a PR review checklist. The lesson's rule of thumb: if you keep explaining the same thing to Claude, that's a skill waiting to be written.
The description decides when a skill activates. Claude compares each request against all available skill descriptions and activates the ones that match; the terminal then shows a line such as "Successfully loaded skill" for pr-review.
Where a skill lives decides who gets it. Personal skills in ~/.claude/skills (on Windows, C:/Users/<your-user>/.claude/skills) follow you across projects. Project skills in a repo's .claude/skills are version-controlled and reach anyone who clones it, which is where team standards such as brand guidelines belong.
Skills load on demand and need no explicit invocation. CLAUDE.md loads into every conversation and slash commands must be typed, while skills load only their name and description up front and activate when Claude recognizes the situation, so they don't fill the context window. The lesson names code review standards, commit formats, brand guidelines, doc templates and framework debugging checklists as good fits.
Building effective human-agent teams (beta): 05-Some practical ways to get started
Start small: one space, a few people, one agent. For the first two weeks the lesson recommends a high-trust team of three to five with a project to finish together, sharing one collaboration space and one multiplayer agent, configured most commonly through Claude Tag or the Claude Managed Agents API.
Make the team's work public and written by default. Decisions made in meetings or DMs get posted the same day, because for an agent anything not written down and accessible doesn't exist. The team writes a roster with one owner per recurring job, agents included (the agent can propose it, people decide), and pins a measurable, ambitious north star where the agent can read it; people set the north star.
Give the agent one visible, reviewed job first. The suggested starter is a morning briefing for the whole team, with a person reviewing it and giving feedback for the first few days. Every task should come with a rubric for what "passing" looks like, which the lesson says scales trust fastest.
Widen autonomy per kind of task, after repeated success. Once the agent has handled a kind of task well several times in a row, it gets more latitude on that task only. Anything explained twice becomes written instructions (skills), and a weekly retro of humans and agents records what works, saved so other agents can reuse it.
Building effective human-agent teams (beta): 04-Organizational checklist
Check five readiness conditions before bringing agents into a team. The lesson's questions are whether work is open and searchable rather than in private documents and DMs; whether ownership is written down, agents included; whether every teammate, agents too, has the tools for the job; whether an agent's key work can be checked by a rubric, test or second agent before a person sees it; and whether there's a written north star. It gives a consequence for each gap: agents fall out of date, work gets duplicated, agents without access guess or do thin work, finalizing takes longer, and nobody can be proactive about what comes next.
Building effective human-agent teams (beta): 03-What a strong human-agent team looks like
Agents raise the cost of misalignment, so team basics matter more. The lesson argues that human-agent teams complete tasks faster, which makes errors and misalignment costlier, so clear roles, a written north star, information access and trust become more important than on teams without agents.
Work in public and give every teammate a defined role. For an agent, unwritten or inaccessible information doesn't exist. The lesson calls for one roster, one set of artifacts and one working space, with the right tools for each human and agent and human judgment kept on the most important decisions.
A human-set north star makes agents proactive; autonomy follows reliability. An agent that knows the goal can bring useful work toward it unprompted, and autonomy is granted in proportion to demonstrated reliability, then expanded deliberately. The exercise prompt has Claude draft a roster for a real project, keep judgment calls with named people, and propose a one-sentence north star for the team to correct.
Building effective human-agent teams (beta): 02-How is a multiplayer agent different from traditional AI tools?
A multiplayer agent acts as itself, not as an extension of you. A single-player agent carries your credentials and knows what you know, while a multiplayer agent has its own identity, so the team decides its access and tools. Per the lesson, its other two defining capabilities are shared memory that grows from everyone who works with it and shared team context that keeps it current.
Three questions tell whether an AI tool is a tool or a teammate. The exercise prompt asks whether it acts under its own name and sign-in or yours, whether it remembers goals between conversations, and whether it reads the team's shared spaces or only what you paste in. Claude then identifies what the team is likely re-explaining or losing, and the smallest change toward "teammate".
Building effective human-agent teams (beta): 01-Why multiplayer AI matters
Single-player AI speeds individuals but silos the team's information. The lesson's image is a "super suit" that makes one person faster on their own tasks. It uses the fictional Lantern team, about to launch a health tracker app, to argue that siloed context hurts agent performance more as a team grows, with repeated questions answered differently.
A shared space turns AI requests into team knowledge. When a meeting summary or calendar update is requested in a space every human and agent can see, it becomes knowledge the team builds on, which the lesson says lets agents be more proactive and personalized toward a common goal. The exercise has a team list three weekly recurring questions and ask Claude what goes wrong when answers differ and what one shared agent answering in public would change.
AI Fluency for students: 05-Being the human in the loop
Being the human in the loop means you make every decision. The lesson defines it as deciding what to ask, judging whether the output makes sense and is good enough to use, and bringing your own judgment, creativity and ethics rather than passively accepting what comes back.
Write a personal AI commitment that's honest, not aspirational. It should cover when you will and won't use AI (your "red lines"), how you'll use it for learning, when and how you'll disclose AI help, and how you'll keep your skills sharp. The exercise also asks how you'd want classmates, professors and employees to use AI, and the lesson suggests sharing the commitment with friends or mentors so others can hold you to it.
Keep reflecting on whether your AI use helps you grow. The questions it poses are whether you're developing the skills you'll need or just completing tasks, whether you're honest about AI's role in your work, and whether your use fits your values. Its claim is that the 4D habits (delegation, description, discernment, diligence) will carry over to AI applications that don't exist yet.
Human insight, judgment and care stay irreplaceable. The lesson argues AI can help you learn faster and express your talents and experience more clearly, but not substitute for them, and that fluent users will help steer how AI is used in their fields instead of just going along with it.
Treat AI as a career thinking partner, not a content generator. The lesson says generic AI-written resumes and cover letters are easily spotted and don't impress employers, and that career decisions like "what do you want to do with your life?" shouldn't be handed over to AI; sometimes the right call is not to use it at all.
AI supplies the market information; you supply self-knowledge and values. AI is good at researching emerging roles, skills employers want, salary progressions in specific cities, and paths others took (e.g. teaching to corporate training). Only you know what energizes you and which trade-offs you'll accept, such as salary versus flexibility. The lesson suggests having AI ask you questions to surface goals you haven't stated, then narrowing to 2–3 roles and noting the skill gaps.
Close skill gaps with specific goals and AI as an active coach. "Help me learn data analysis" is too vague. The lesson's alternative describes the actual need, analyzing survey data for a marketing take-home, and asks for a plan with practice. Then use AI for industry practice scenarios, feedback, and role-played interviews, and check regularly whether you're learning or just going through the motions.
In the job search, AI coaches but you present yourself. AI can brainstorm, find transferable skills, run interview practice and produce drafts to borrow from, but you're responsible for how you're represented and must test its suggestions against your real professional identity.
AI fluency is itself a career skill to show off. The lesson advises keeping track of your AI use, disclosing it when relevant, and listing AI fluency on your resume, because employers want people who can work with AI effectively.
AI Fluency for students: 03-AI as a learning partner
Letting AI think for you leaves you stranded when it counts. The lesson argues that leaning on AI skips building critical-thinking skills, which shows up in a no-AI exam, a job interview where you have to explain your reasoning, or at work when you can't tell whether AI advice is "genius or garbage".
Delegate with your learning goal in mind. Before opening an assistant, ask what the work is meant to teach you. If the goal is better argumentative writing, AI shouldn't write the arguments but can act as a debate partner throwing counterarguments; the lesson also suggests choosing platforms built for learning.
Describe the help you want: coach, not substitute player. Assistants default to direct answers, so ask for a tutor who only asks questions, hints without solving a logarithm problem, questions that deepen your own poem analysis, practice problems, or AI playing your student so you teach it. The exercise builds a reusable "study buddy" configuration with protocols per need (problem-solving, exam prep, writing, planning) and tests whether it slips back into giving answers.
Discern honestly whether you're learning or along for the ride. The gut check is whether you can explain it to someone else, solve a similar problem without AI, and say why it works. Frustration counts as a sign of learning, and important facts from AI should be verified against non-AI sources.
Diligence means following policy, disclosing, and owning every submission. The lesson's three parts are using the AI tools your school allows and following its rules, documenting AI use even when not required, and being able to explain, defend and apply everything you hand in. If you can't say why you took an approach because AI chose it, you haven't learned it.
AI fluency means augmenting your work, not automating it. The lesson defines fluency as using AI effectively, efficiently, ethically and safely as a responsible human in the loop, and argues augmentation matters most in learning, where the aim is for AI to help you do your work better rather than do it for you.
Delegation rests on problem, platform and task awareness. You first get clear on the goal (what successful studying for this test looks like), then pick a system suited to it, since some are built for reasoning and some for student learning. Finally, divide the work: humans bring creativity, judgment and real-world context; AI brings speed, consistency and the ability to process large volumes of information.
Description covers the product, the process and the AI's behavior. Product description spells out length, key messages, audience and style; process description says how to approach the task, such as step by step or from several perspectives; performance description sets the role, such as critical editor or supportive brainstormer.
Discernment evaluates the same three levels, and loops with description. You judge whether the output is accurate and useful, whether the reasoning and assumptions hold, and whether the AI kept the role you asked for, including noticing when it surfaces something new. Describe, discern and refine form the feedback loop the lesson says turns AI from a tool into a thinking partner.
Diligence is about choosing tools carefully, disclosing, and owning the result. Creation diligence weighs privacy, security and fit when choosing a system; transparency diligence tells professors, teammates and employers how AI helped; deployment diligence means verifying and taking responsibility for the output ("AI might draft the email, but you send it"). The lesson expects the 4Ds to stay relevant as the technology changes.
AI Fluency for students: 01-Welcome to AI Fluency for students
AI fluency is a set of lasting skills, not tool tips. The hosts (Zoe, Maggie Vo and Alex Albert) say most AI guidance is use cases and tricks that go stale with new models, while the skills they've seen endure concern how to use AI effectively, efficiently, ethically and safely. That means when to hand work to AI, when not to use it at all, how to choose an assistant and check its accuracy, and whether and how to tell teachers or employers.
The course applies the 4Ds to learning and careers. It starts with delegation, description, discernment and diligence, applies them to learning concepts more deeply and to career planning and job search, and ends on being the human in the loop. The stated aim is to make AI a partner that helps you do your work better rather than a tool that does it for you.
AI Fluency for pK-12 Train the Trainer: 04-Learner workbook
The captured text contains no deck or guide content. The archived page is just a "Loading" placeholder for an interactive viewer, so none of the deck or facilitator guide is available to summarize. The companion "How to use the kit" lesson describes this page as the workshop deck with toggleable speaker notes holding the facilitator guide, downloadable as PDF or HTML.
AI Fluency for pK-12 Train the Trainer: 02-How to use the kit
The kit has three parts: deck, facilitator guide and learner workbook. The deck is the whole workshop slide by slide; the facilitator guide holds key points and activity setup for each slide and appears as toggleable speaker notes under the slide; the workbook goes to participating teachers so they can practice the 4Ds and keep their responses.
The deck runs in the browser and downloads for offline use. Navigation is by Back/Next, arrow keys or a "Jump to section" menu, the "Meet your facilitator" slide can be personalized and is saved in the browser, and the Download menu exports the deck and guide as PDF or HTML for offline presenting or printed handouts.
AI Fluency for pK-12 Train the Trainer: 01-Introduction: From learner to trainer
Educators need a voice in today's AI decisions about classrooms. The lesson argues that decisions made now will shape classrooms for years, that teachers are closest to the impact, and that no algorithm can replicate the relational work at the heart of teaching. That is its stated reason for training educators to lead their colleagues.
The kit assumes trainers have already built their own fluency. It builds on the AI Fluency for pK-12 Educators course's 4D Framework, guardrails and judgment, adding a ready-to-run deck, a facilitator guide with slide-by-slide talking points and timing, and grade-band exercises so trainers can lead colleagues through it in their own voice. Anyone who hasn't taken the main course is told to start there.
AI Fluency for educators: 04-Applying AI Fluency to learning materials and assignments
Accumulated context makes each new material fit the sequence. With past conversations, uploaded files and connected tools, the AI already knows your objectives, the learning journey you've mapped and your constraints, so you never start from scratch. The running example is journalism students stuck on null and alternative hypotheses: the AI knows this is a week-four objective, that these students struggle with abstraction, and that social media analytics has served as the bridge concept.
Delegate the confusion point to the teacher, the variety to the AI. Problem awareness says why students are confused and what has to change, while AI is good at generating varied practice scenarios that fit the course's progression; the two refine together. The lesson's exercises apply the same approach to slide decks, study guides, in-class activities and 5–10-question quizzes, each ending in a check for accuracy, alignment and bias.
Describe by referring back to shared context, then add specifics. The example prompt recalls that "my journalism students need concrete examples before abstractions" and builds on last week's social media examples. It then specifies product details (numbered worksheet, answer key on a separate page), process (target misconceptions about identifying variables first, build complexity gradually) and performance (creative scenarios at a 10th-grade reading level, flag anything too complex).
Explain why suggestions work or fail, to keep the loop improving. Don't just accept a good scenario or reject an overly complex one; saying why grows the context and improves later suggestions. Discernment should also catch possibilities, such as an approach borrowed from another field that clarifies the concept.
Diligence, and the integrity problem AI creates, belong to the educator. That means protecting sensitive data, checking citations, sharing diligence statements with students, and reviewing for accuracy, bias and alignment, since the educator owns the impact. The lesson acknowledges AI can pass many assignments at a passing grade or better, says there are no simple solutions across contexts from kindergarten to graduate school, and argues the payoff is coherent quality more than speed.
AI Fluency for educators: 03-Applying AI Fluency to course design and learning outcomes
Rich shared context turns AI into a colleague who knows your teaching. Presenter Joe Feller argues AI's most transformative capability for educators is holding a large context while helping with interconnected decisions, applied here to course design's three tasks: choosing essential content, mapping the learning journey, and writing learning objectives.
Decide what you need and why before choosing how to collaborate. Filling out details under topics you already have calls for different help than organizing concepts you know must be included. The description should then bring the AI into the real problem: not "introductory statistics topics" but a stats course for journalism students who are anxious about math or doubt its relevance, with a request for concepts that address those concerns and build confidence.
Ask the AI to play a student to test the course flow. Once a sequence is drafted, the AI can say where a student would get confused, what background each stage needs, and what support transitions require. The lesson calls this an always-available student focus group that teachers often forget to use; the exercise sequences 3–4 sessions this way.
Earlier context-building lets you iterate on learning objectives quickly. That context, or a syllabus plus a description of your teaching approach, supports objectives that are measurable, motivating, true to your philosophy and aligned with institutional requirements. Faster drafting allows more experiments, such as mapping course outcomes to resume skills to motivate students.
Keep responsibility and document the collaboration openly. The lesson says you aren't outsourcing decisions, so record key choices and rejected suggestions and share the process with students and peers to model responsible use. It argues the real gain beyond saving time is surfacing hidden assumptions and unexpected connections, producing courses better than teacher or AI would design alone.
AI Fluency for educators: 02-AI Fluency Framework review
Fluency means augmenting your own work, not automating it away. The lesson defines AI fluency as using AI effectively, efficiently, ethically and safely as a responsible human in the loop, in contrast to asking AI to do the work without thinking about what's asked or its impact, and says this matters most in learning.
Delegation draws on three awarenesses: problem, platform and task. Clarity about the goal, kept as a "North Star" though it can be revised, comes first. Next is choosing a system whose capabilities fit, since some excel at reasoning and some are built for learning. Last is splitting the work so humans contribute creativity, judgment and real-world context and AI contributes speed, consistency and volume.
Description specifies the product, the process and the AI's role. Product means length, key messages, audience and style; process means how to approach the task, such as step by step or from several perspectives; performance means how the AI should behave, such as challenging critic or supportive brainstormer. The lesson frames this as conversation with a collaborator, not memorized prompts.
Discernment judges the same three levels and feeds a refinement loop. It asks whether the output is accurate and useful, whether the reasoning and assumptions hold, and whether the AI kept its role and pushed back when it should, and it also notices useful surprises. Describing, discerning and refining in turn is where the lesson says fluency develops, turning AI into a thinking partner.
Diligence covers choosing tools carefully, disclosing, and owning the result. Creation diligence weighs privacy, security and fit; transparency diligence tells the people affected how AI helped; deployment diligence verifies accuracy and appropriateness and owns the outcome. The lesson expects the 4Ds to hold as AI capabilities change.
AI Fluency for educators: 01-Introduction to AI Fluency for Educators
The open question is how AI enters education, not whether. The presenters (Zoe, Rick Dakan, Maggie Vo, Joe Feller) say students already use AI, employers increasingly expect graduates to be fluent with it, and institutions worldwide are working out responsible integration, so educators have a chance to model thoughtful, critical engagement.
The course applies the 4Ds to course design, materials and assessment. It treats AI as a thinking partner for designing courses, creating learning materials, and building assignments and assessments that keep the teacher's vision and academic integrity, with the goal of challenging assumptions and personalizing learning while keeping human expertise and pedagogical values at the center. It assumes the AI Fluency: Framework & Foundations course, and companion courses exist for teaching fluency to students and for students themselves.
Start by building a reusable document describing your teaching context. The exercise has the educator reflect on values, constraints and students, then talk it through with an AI that interviews them or asks what else it needs, and synthesize the result into a structured document to paste into later conversations. The lesson's premise is that AI helps more when it understands your situation, values and constraints.
Introduction to subagents: 04-Using subagents effectively
Delegate only when the intermediate work doesn't matter. The lesson's single decision rule: if you need just the result, hand it to a subagent; if you need to see and react to each step, keep it in the main thread. Research is the classic case — a subagent can read dozens of files tracing authentication and return only a line like "JWT validation happens in middleware/auth.js line 42".
A separate reviewer context gives better code reviews. The lesson says Claude reviews code more effectively when it is presented as someone else's, so the thread that built a feature over many turns gives weak feedback on it. A reviewer subagent runs git diff and reads the changed files without that history, and its system prompt can encode project-specific review standards for consistency across a team.
Custom system prompts justify subagents for non-coding work. Claude Code's default prompt favours concise, code-focused output, which the lesson says is wrong for a landing page or email campaign. Its examples are a copywriting subagent with tone, audience and style instructions, and a styling subagent told to read design-system files before writing CSS.
"Expert" persona subagents add nothing. Prompts like "you are a Python expert" or "Kubernetes specialist" give no capability the main thread lacks, since Claude already has that knowledge, so the overhead of a subagent buys nothing.
Pipelines and test runners lose information you need. A reproduce-debug-fix chain of three agents fails because each step depends on the last's discoveries, which get lost in handoffs. A test runner that returns only "tests failed" hides the output needed to diagnose; the lesson reports that in testing this pattern performed worst of all configurations.
Introduction to subagents: 03-Designing effective subagents
The description decides both when a subagent runs and what it's told. Every subagent's name and description go into the main agent's system prompt, steering which one it launches, and the main agent also uses the description as guidance when writing the subagent's input prompt. Adding "You must tell the agent precisely which files you want it to review" to a code reviewer's description turned a vague "use git diff" prompt into one listing the files; "return sources that can be cited" works the same way for a web-search subagent.
Defining an output format is the single biggest improvement. The lesson argues it gives the subagent natural stopping points — it is done once every section is filled — whereas without one subagents struggle to judge when enough research is done and run much longer. Its code-review template has Summary, Critical, Major and Minor Issues, Recommendations, and Approval Status sections.
Ask explicitly for obstacles, or the main thread rediscovers them. Workarounds, environment quirks, commands needing special flags, and problem dependencies or imports should come back in the summary to avoid wasted time and tokens. An "Obstacles Encountered" section in the output template is the lesson's way to surface them reliably.
Grant each subagent only the tools its job needs. This prevents unintended side effects and clarifies roles when there are several subagents. The lesson's mapping: research gets only Glob, Grep and Read; a reviewer adds Bash for git diff but no Edit or Write; only code-modifying agents such as a styling agent get Edit and Write.
A custom subagent is a markdown file with YAML frontmatter. The frontmatter tells Claude when to use it and the body directs the subagent itself. Placement sets scope: .claude/agents/ is project-level, ~/.claude/agents/ is user-level and shared across all projects on the machine.
Create subagents by asking Claude to write the file. The written lesson says the /agents wizard shown in the video was removed in Claude Code v2.1.198, so scope, tools, model and colour now go into the request; the video's narration still presents /agents as the easiest route. Either way the recommended path is letting Claude generate the name, description and system prompt from a description of the job.
Fields set tools, model and identity.tools lists accessible tools — a reviewer can drop edit tools but keep execution tools to find pending changes. model takes an alias (sonnet, opus, haiku, fable), a full model ID, or inherit, with Haiku for fast tasks, Opus for complex analysis and Sonnet between; name is referenced as @agent-name and color marks the subagent in the UI.
The body below the frontmatter is the system prompt. It sets what the subagent focuses on, how it analyses, and how it reports back; the lesson says its specificity is the difference between a useful subagent and one that misses the point.
The description controls delegation, so tune it when triggering fails. It must be a single line (escaped \n for breaks); including "proactively" makes Claude delegate without being asked, and concrete example conversations improve its judgment. Test by making code changes and asking for a review, restarting Claude Code first if the agents folder didn't exist at session start.
Subagents protect the finite main context window. Each runs in its own context, starting from its configured system prompt plus a task description written by the parent agent, and only a summary returns; the rest is saved to a separate transcript file. The stated tradeoff is that the main conversation can't see how the subagent reached its conclusions.
Delegated digging leaves only question and answer behind. In the lesson's example, finding which service handles refunds might take 15 file reads and several searches; via the Explore subagent the main context records only the question and the answer.
Built-in subagents cover general work, exploring and planning. Claude Code ships three: General purpose handles multi-step tasks needing exploration and action, Explore does fast codebase search and navigation, and Plan does research during plan mode. Custom subagents add your own system prompts and tool access, such as a code reviewer or test writer.
Less context noise means longer, more effective sessions. The lesson frames the benefits as focused pieces of work, a clean main context, and concise summaries of only what is needed.
Workflows trade flexibility for accuracy and testability. A workflow is a predefined series of Claude calls for a known problem; because each call handles one small subtask, the lesson says accuracy is generally higher and every step can be evaluated, but the user must supply the exact inputs the flow expects.
Agents trade reliability for flexibility. Given basic tools, Claude plans its own path, combines tools in unexpected ways and can ask the user for missing input; the cost is a lower task-completion rate and steps that are hard to instrument, test and evaluate because they are not known in advance.
Default to workflows; use agents only when truly required. The lesson's recommendation is that users want a product that works 100% of the time, not a fancy agent, so agents are reserved for problems whose solution path cannot be predetermined.
Claude acts blindly unless it can observe its results. A click or keystroke changes the interface without Claude knowing how, which is why computer-use tools return a screenshot after every action so it can judge success and plan the next step.
Read a file before modifying it. The example has Claude read the 31 lines of main.py before adding an "/items" route, so the edit fits the existing code; the lesson calls this a step many agent builders overlook.
System prompts can tell an agent how to verify its output. For a video-posting agent, suggested instructions are to run whisper.cpp for timestamped captions to check dialog placement, use FFmpeg to extract frames to check visual quality, and check file sizes and formats before uploading.
Every agent action should be followed by some verification. The lesson's rule is that inspection after each step lets the agent catch errors early and self-correct when results are unexpected.
Agents get a goal and tools, not a fixed sequence. That lets one agent handle many tasks once it works reasonably well, though the lesson flags significant drawbacks in reliability and cost to be covered later.
Simple tools combine to cover diverse requests. With get_current_datetime, add_duration_to_datetime and set_reminder, Claude answers "What's the time?" with one call, chains two for "what day is it in 11 days", uses all three for a gym reminder next Wednesday, and asks the purchase date before computing when a 90-day warranty expires.
Give agents reasonably abstract tools, not hyper-specialized ones. Claude Code has generic tools (bash, glob, grep, read, write, edit, webfetch) and no "Refactor", "Run Tests" or "Install Dependencies"; it installs dependencies by reading project config and then running commands through bash.
The right tool abstraction lets agents work autonomously or collaboratively. A video agent with bash (for FFmpeg), generate_image, text_to_speech and post_media can either make and post a Python video end to end, or first generate a sample image for the user to approve before continuing.
One generic prompt yields mediocre output across different request types. A video-script tool should write an educational, definition-led script for "programming" but a high-energy, hook-driven one for "surfing"; the same prompt for both suits neither.
Routing uses two Claude calls: categorize, then process. The first call classifies the input into a defined category (examples: entertainment, educational, comedy, personal vlog, reviews, storytelling), so "Python functions" comes back "Educational"; the second call uses that category's specialized prompt.
Each input goes to exactly one specialized pipeline. Pipelines can carry their own prompts, tools, APIs or processing steps, new categories can be added without touching existing ones, and only the needed processing runs.
Routing fits distinctly different request types with clear categories. The lesson puts the useful range at 3–10 meaningful categories, and argues the upfront cost of building several pipelines pays off in significantly better results when quality matters more than simplicity.
Chaining splits one large task into sequential, focused subtasks. The example video-marketing pipeline finds trending Twitter topics, has Claude pick one, research it and write a script, then makes an avatar video and posts it, with optional non-LLM processing between steps.
Adding more "DO NOT" constraints doesn't stop violations. The lesson's scenario is an article prompt that accumulates rules against emojis, mentioning being an AI and a cringey tone, yet Claude still sometimes breaks them.
Accept an imperfect draft, then fix it in a focused revision call. The second prompt lists specific steps — remove self-identification as an AI, remove all emojis, replace cringey writing with technical-writer prose — which works because Claude handles one aspect at a time.
Chaining suits complex, many-constraint tasks Claude follows inconsistently. It also fits when outputs need processing or validation between steps; the lesson claims it is often more reliable than one complex prompt.
Claude on Google Cloud: 61-Parallelization workflows
One giant prompt juggling many analyses confuses Claude. In a material-designer app choosing among metal, polymer, ceramic, composite, elastomer or wood, adding detailed criteria for every material to one request leaves the model distracted weighing all pros and cons at once.
Run specialized sub-tasks in parallel, then aggregate. The same part image goes out in separate requests, each with criteria for one material; a final aggregator call compares those analyses and recommends a material rather than evaluating from scratch.
Parallel sub-tasks need not be identical. Each can have its own prompt, tools or approach, and each can be tested and optimized independently; adding a material doesn't complicate the others, and parallel execution is often faster than sequential.
Use it for tasks that decompose into independent sub-problems. The lesson points to cases weighing multiple options or several kinds of analysis where each benefits from specialized prompting.
How well you understand the task decides workflow versus agent. Use a workflow when you can picture the exact steps or the UX constrains users to set tasks; use an agent when you don't know what task or parameters Claude will get.
Image-to-CAD is a textbook workflow. The app has Claude describe an uploaded image of a metal part, model it with the CadQuery library, render the model, then grade the render against the image and loop to fix issues, producing a STEP file.
The evaluator-optimizer pattern loops a producer and a grader. The producer creates output, the grader checks it against criteria and sends feedback on rejection, and the cycle repeats until the grader accepts.
Named workflow patterns are reusable recipes, not implementations. The lesson says they save time and avoid pitfalls others have hit, but you still write the code yourself.
MCP primitives differ by who controls them. Tools are model-controlled, resources app-controlled and prompts user-controlled; the summary line is that tools serve the model, resources serve your app and prompts serve your users.
Use tools to extend what Claude can do. Claude decides when to call them, as when it picks a JavaScript execution tool to compute the square root of 3 accurately.
Use resources to get data into your app. Examples are autocomplete options, context added to messages before sending, and document lists; in claude.ai, "Add from Google Drive" fetching your documents is resource behavior.
Use prompts for workflows users trigger on demand. Triggered by buttons, menus or slash commands, they suit conversation starters, task templates and specialized workflows, like the starter buttons below the claude.ai chat input.
The client lists prompts and fetches them with arguments interpolated. list_prompts returns the session's prompts; get_prompt passes a name and an args dict (such as doc_id for the "format" prompt) and returns messages ready to send to Claude.
Prompt function parameters become interpolation variables. The server substitutes the supplied argument values into the prompt text, so the client never builds the prompt itself.
In the CLI, prompts appear as slash commands. Choosing "format" asks for its arguments (a document), then the client retrieves the filled prompt, sends it to Claude, Claude runs any tool calls, and the result comes back.
Prompts separate prompt logic on the server from execution in the client. The lesson frames them as pre-built, well-tested workflows combining the server's tools and resources that users trigger with a simple command.
Server-authored prompts beat what users write themselves. A user typing "convert report.pdf to markdown" gets decent output, but the lesson argues a prompt engineered and tested by the MCP server's authors gives superior results.
An MCP prompt returns user and assistant messages ready for Claude. It is defined with the @mcp.prompt decorator (name "format", a description) on a function whose Field-described doc_id parameter is interpolated into instructions to rewrite the document in markdown using the edit_document tool; base.UserMessage comes from mcp.server.fastmcp.prompts.
The MCP Inspector's Prompts tab shows exactly what gets sent. Supplying a doc_id such as "outlook.pdf" displays the interpolated message.
Prompts should be high quality and fit the server's purpose. Cited benefits are quality control, consistency, domain specialization and reuse across clients; formatting prompts fit a document-management server.
Resources put data straight into prompts, skipping tool calls. When a user types "@report.pdf", the client sends a ReadResourceRequest and the ReadResourceResult's content can be inserted into the prompt, so Claude has the document immediately.
The client's read_resource must parse by MIME type. It calls session().read_resource(AnyUrl(uri)), takes contents[0], and for TextResourceContents returns json.loads of the text when mimeType is "application/json", otherwise the plain text.
Resources suit stable, frequently referenced content; tools suit dynamic operations. Resources reduce API calls and make content immediately available; tools fit when the model should decide from the conversation whether to fetch information.
Resources are read-only data endpoints, like HTTP GET handlers. Clients request a URI with ReadResourceRequest and get a ReadResourceResult; a mime_type hints at the data type, which can be strings, JSON or binary.
Resources are either direct or templated. Direct ones have static URIs ("docs://documents"); templated ones carry parameters ("docs://documents/{doc_id}") that the Python SDK parses and passes as keyword arguments, so URI parameter names must match function parameter names exactly.
The SDK serializes return values automatically. list_docs returns a Python list with mime_type "application/json" and fetch_doc returns a string as "text/plain", raising ValueError for unknown IDs, with no manual JSON conversion.
The MCP Inspector shows exactly what clients will receive. Started with "uv run mcp dev mcp_server.py", it shows direct resources and resource templates separately and displays the response structure, including MIME type and serialized data.
@-mentions pair a direct list with a templated fetch. The direct resource feeds autocomplete with document names and the templated one fetches a mentioned document's content, injecting it into the prompt without the AI needing tools.
Real projects usually build a client or a server, not both. This course builds both only to show how they work together.
A custom MCPClient class wraps the SDK's ClientSession. The session is the actual server connection and needs resource cleanup, which the wrapper handles along with connection management.
The CLI needs only list_tools and call_tool. list_tools returns session().list_tools().tools; call_tool forwards the tool name and Claude-supplied input to session().call_tool and returns the result.
Test the client directly, then end to end. Running "uv run mcp_client.py" lists read_doc_contents and edit_document with schemas; asking the app about report.pdf should have Claude choose read_doc_contents, the client call it, and Claude answer from the returned contents.
The Python MCP SDK's browser inspector tests a server without an application. Running "mcp dev mcp_server.py" starts it; the screenshot shows a proxy on port 6277 and the inspector at 127.0.0.1:6274, and the lesson warns the UI is still changing.
The Tools tab lets you run tools individually and in sequence. After "List Tools", you select read_doc_contents, enter an ID like "deposition.md" and run it; editing with edit_document and re-reading confirms the change applied.
The inspector gives a fast edit-test-debug loop. The lesson's claim is that it catches issues before integrating with Claude or other apps.
Claude on Google Cloud: 52-Defining tools with MCP
The Python SDK replaces hand-written JSON schemas with decorators. A server is one line, FastMCP("DocumentMCP", log_level="ERROR"), and @mcp.tool with a name, description and Field-described parameters generates the schema Claude needs.
The example server has read and edit tools over in-memory documents. Documents live in a dictionary of ID to content; read_doc_contents returns a document's text and raises ValueError for unknown IDs.
edit_document does an exact-match find-and-replace. It takes doc_id, old_str and new_str and uses Python's str.replace, so old_str must match exactly, including whitespace.
SDK tools are plain, testable Python functions. Cited benefits are type-hint validation, Field descriptions that guide Claude, errors via ordinary exceptions, and automatic registration.
The project is a CLI chatbot over documents, with client and server. The MCP server exposes tools to read and update in-memory documents (document.pdf, spreadsheet.xlsx, report.txt, spec.md); the client handles users and talks to Claude.
Real projects usually build only one side. You'd build a server to expose your service to AI models, or a client to use others' servers; this one builds both purely for teaching.
Setup is an API key, dependencies, then one run command. Put ANTHROPIC_API_KEY in .env, install with uv (recommended) or pip, run "uv run main.py" (or "python main.py"), and check the chat by asking "what's 1+1?"; the starter cli_project.zip has basic chat, and cli_project_COMPLETE.zip is the finished version.
MCP is transport agnostic. The common setup runs client and server on one machine over standard input/output, but they can also connect over HTTP, WebSockets or other protocols.
Two request/result pairs carry most of the work. ListToolsRequest/ListToolsResult asks what tools the server offers; CallToolRequest/CallToolResult runs a named tool with arguments and returns the result.
A single question triggers a long relay through the client. For "What repositories do I have?", your server gets the tool list via the client, sends query plus tools to Claude, receives a tool-use request, has the client send CallToolRequest to the GitHub MCP server (which calls GitHub), then returns the result to Claude in a user message for the final answer.
MCP moves tool-writing work from your server to MCP servers. Your server becomes an MCP client connecting to servers that hold tools, prompts and resources and wrap outside services like GitHub, AWS or databases.
Covering a large service yourself means many tools to maintain. Answering "what open pull requests are there across my repositories?" in full generality would require schemas and functions such as get_repos, search_issues, update_issue, create_issue and create_file.
Anyone can write an MCP server, often the provider itself. The lesson gives AWS releasing an official server as a possible example, and you can wrap any service you need.
MCP complements tool use rather than replacing it. MCP is about who builds and maintains the tool schemas and functions; tool use is how Claude calls them, and calling an API directly means writing those definitions yourself.
Claude on Google Cloud: 48-Prompt caching in action
Cache tool schemas by marking a copy of the last tool. Clone the tools list and its last schema, add cache_control {"type": "ephemeral"} to the clone, and pass that, so the original definitions aren't mutated and later reordering doesn't break.
Cache the system prompt by sending it as a text-block list. The system parameter becomes a list holding one text block with the cache_control field.
Usage fields show whether the cache was written or read. The first request reports cache_creation_input_tokens, identical repeats report cache_read_input_tokens, and changing only the system prompt can show both — but only if the tools alone reach the minimum length, since a breakpoint below it writes nothing.
A single changed character invalidates the cache entry. That makes stable tool schemas and system prompts ideal candidates, and the lesson recommends building caching into chat functions by default.
Claude on Google Cloud: 47-Rules of prompt caching
Caching requires a manual breakpoint on a block. Everything before and including the breakpoint is cached and reused only if identical up to that point; adding cache_control {"type": "ephemeral"} requires the longhand content-block form, not the shorthand string.
Breakpoints can go on system prompts and tool definitions. These are the most common opportunities because they rarely change, and breakpoints also span messages, including assistant messages.
Tools, system prompt and messages are joined in that order. A breakpoint on the last tool caches the tools but not the system prompt or messages; up to four breakpoints are allowed.
Content below a model-specific minimum silently isn't cached. For Claude Haiku 4.5, the course's model, the minimum is 4,096 tokens summed across the cached content; no error returns, and both cache_creation_input_tokens and cache_read_input_tokens read 0.
Without caching, Claude discards its input-processing work after each request. The lesson describes tokenizing, creating embeddings and adding context before generating, all thrown away once the response is sent.
Conversations force reprocessing of identical earlier content. A follow-up includes the original message and Claude's reply, so the same text gets processed again moments later.
Prompt caching saves that work for reuse on matching content. The first request writes it to a cache acting as a lookup table and follow-ups read it, making requests faster and cheaper.
The cache is short-lived and needs exact matches. It lives 5 minutes, but the lesson says repeated content is still extremely common, in conversations, repeated document references and iterated prompts.
Citations show users answers came from their documents, not memory. Without them users can't verify information or tell it came from supplied sources.
Enable citations with a title and citations flag. Add "title" (e.g. "earth.pdf") and "citations": {"enabled": True} to the document block; responses then carry cited_text, document_index, document_title, start_page_number and end_page_number.
Plain-text documents get character locations instead of pages. A text source with media_type "text/plain" returns CitationCharLocation objects, allowing exact sentences or paragraphs to be highlighted.
Citations pay off in interfaces that display them. Numbered references users can hover or click to see the document and pages let them verify claims, which the lesson calls essential for sensitive documents or users who want the original source.
Images go in as base64 blocks under hard size and count limits. The lesson lists up to 100 images per request, 10MB per image after base64 encoding, 8000px max side for a single image and 2000px when sending several. Each image costs tokens of ⌈width/28⌉ × ⌈height/28⌉, and the image block sits in the user message beside the text block.
Simple vision prompts give poor results even on clear images. Asked plainly how many marbles were in a photo of 12, Claude answered 13. The lesson's claim is that the usual prompt-engineering techniques (detailed steps, examples, breaking the task down) apply to images just as they do to text.
Giving a counting method or a worked example fixes the error. A prompt that numbers each marble and then re-counts row by row from the bottom-left produced the correct 12. So did a one-shot setup: an image labelled as 11 marbles, followed by the target image.
Real-world vision tasks need a full analysis framework, not a one-line ask. For insurance wildfire assessment from satellite images, the prompt walks through finding the residence, tree overhang (in 0-25/25-50/50-75/75%+ bands), fire vulnerability, and defensible space, then a 1-4 rating. On a heavily wooded property Claude returned "3 (High Risk)", which the lesson reports as correct.
Extended thinking trades cost and latency for accuracy on hard tasks. You pay for every thinking token and wait longer for the reply. The lesson says to turn it on only after evaluations show that prompt optimization alone still falls short.
With thinking on, responses carry a thinking block before the text. Each thinking block has a cryptographic signature, so the reasoning cannot be edited when you send it back in later turns; changing it makes signature validation fail. The lesson's reason is that Claude relies heavily on that content to generate its response.
Flagged reasoning arrives as an encrypted redacted thinking block. You cannot read it, but you should still pass it back in later turns so Claude keeps the context of its earlier reasoning. During development, a special trigger string in the message forces a redacted response so you can test how your code handles one.
The thinking budget has a floor and must sit below max_tokens. The minimum budget is 1024 tokens, and max_tokens must be larger (at least 1025 for that budget). In the example, a 1024 budget with max_tokens of 4000 leaves up to 2976 tokens for the answer, set through params["thinking"] = {"type": "enabled", "budget_tokens": ...}.
Chunking cuts each piece off from the document around it. The lesson's argument is that a chunk that no longer knows where it came from, or how it relates to other sections, is harder to retrieve accurately.
Have Claude write a short context snippet for each chunk before indexing. Claude is sent each chunk with the source document and asked for a brief snippet placing the chunk in the whole. The snippet is prepended to the chunk, and the result goes into both the vector and BM25 indexes. In the example, the snippet ties a Software Engineering section to an incident ID that also appears in the Cybersecurity Analysis section.
For documents too large for the context window, send a reduced context. Instead of the whole document, send a few chunks from the start, where summaries or abstracts often sit, plus the chunks just before the target. The sample code uses 2 of each.
The technique pays off where sections depend on each other. It suits technical documents, reports and papers whose chunks refer to concepts defined elsewhere. The cost is an extra API call per chunk, which the lesson considers worth it when context matters.
Hybrid search can still rank the wrong section first. For "what did the eng team do with INC-2023-Q4-011?", the Cybersecurity section came out ahead of Software Engineering, even though the query is specifically about the engineering team.
Re-ranking passes the merged hybrid results through Claude for reordering. The prompt gives Claude the user's question and the candidate documents, and asks for the k most relevant in order of decreasing relevance, returned as JSON. The re-ranker plugs into the Retriever as a reranker_fn parameter.
Ask for document IDs, not text, to keep re-ranking fast. Giving each chunk a unique ID in advance and asking Claude to return only the IDs avoids waiting while it copies out long passages.
Re-ranking fixed the example at the price of an extra LLM call. With the re-ranker, Software Engineering ranked first, because Claude picked up that the question was about the engineering team. The cost is added latency and an API charge on every search, which the lesson judges worthwhile when precise retrieval matters.
Claude on Google Cloud: 40-A Multi-index RAG pipeline
A single Retriever class can wrap both search indexes. Because VectorIndex and BM25Index share the same add_document() and search() API, the Retriever simply forwards documents and queries to each and merges what comes back.
Reciprocal Rank Fusion merges results by rank, not raw score. Cosine similarity and BM25 scores aren't comparable, so each document scores Σ 1/(k + rank) across the indexes. k is usually 60; the lesson uses 1 for readability. In the example, sections ranked (2,7,6) by vector and (6,2,7) by BM25 score 0.833, 0.75 and 0.583, giving the final order 2, 6, 7.
The hybrid search beat vector search alone on the incident query. For "what happened with INC-2023-Q4-011?" it returned Cybersecurity Analysis (the incident report) first, then Software Engineering, then Legal Developments.
The shared interface makes adding more indexes easy. Any new index that implements search() and add_document(), such as one for named entities, is folded into the RRF ranking automatically, whatever the number of indexes.
Semantic search can miss exact terms like incident IDs. A query for "INC-2023-Q4-011" returned Cybersecurity and Financial Analysis, when the right sections were Cybersecurity and Software Engineering. The lesson's explanation is that embeddings match on meaning, not exact strings.
BM25 weights query terms by rarity across the documents. It splits the query into terms, counts how often each appears, and gives rare terms more weight. Chunks with more of the high-weight terms rank higher, so the incident ID counts for far more than a word like "a".
Run lexical and semantic search side by side, then merge. BM25Index has the same add_document()/search() API as the vector index. Run alone, it put the sections that actually contain the ID first. The lesson sets up merging the two result sets as the next step.
Claude on Google Cloud: 38-Implementing the RAG flow
The basic RAG pipeline runs in five steps. Chunk the text by section, embed each chunk, store the vectors in a VectorIndex, embed the user's query, then search for the nearest chunks by cosine distance.
Store each chunk's text alongside its embedding. A vector is meaningless to people, so search results are useless without the content they stand for. Some setups store an ID pointing back to the text instead; the lesson stores the text directly for simplicity.
The example query returned relevant sections with close distances. "What did the software engineering dept do last year?" returned Section 2, Software Engineering – Project Phoenix (distance 0.71), and the Methodology section (0.72); lower distance means more similar. The lesson says later sections will cover cases where this basic approach falls short.
Chunking, embedding and storage all happen before any user query. Using an imaginary two-number model (medicine, software), the medical section embeds as [0.97, 0.34] because of the word "bug", and the software section as [0.30, 0.97]. Normalized to unit length, these become [0.944, 0.331] and [0.295, 0.955] and are stored in the vector database.
The query is embedded by the same model and matched by cosine similarity. The software-engineering question embeds to [0.1, 0.89], normalized to [0.112, 0.993]. It scores 0.983 against Software Engineering and 0.398 against Medical Research, so the software section is returned.
Cosine distance is one minus similarity, so smaller means closer. Similarity runs from 1 (same direction) through 0 (perpendicular) to −1 (opposite). Distance therefore runs from 0 (very similar) to 2 (opposite), and vector database documentation often reports distance.
The final prompt combines the question with the retrieved chunk. The software-engineering section goes into <report> tags beside the <user_question>. That lets Claude answer from your own documents rather than only from its training.
Finding relevant chunks is a search problem, usually solved semantically. Semantic search compares embeddings of the question and of each chunk, so it can find related content even when the words differ.
An embedding is a list of numbers whose features nobody can interpret. Each value runs from −1 to +1 and scores some quality of the text. Labels like "how happy" are only illustrations: the model learns its features in training, and they are not labelled, yet they still allow texts to be compared mathematically.
Claude can't produce embeddings, so Vertex AI supplies a separate model. The lesson uses text-embedding-005 through the google-genai SDK, calling client.models.embed_content with vertexai=True and returning each embedding's values.
Claude on Google Cloud: 35-Text chunking strategies
Bad chunking puts the wrong context in the prompt. In the lesson's example, "How many bugs did engineers fix this year?" can retrieve a medical-research section that calls a pathogen a "bug", rather than the software-engineering section. The result is a wrong answer.
Size-based chunking is simple but needs overlap to keep context. Equal-length cuts split words (a 325-character document cut into three chunks of about 108 characters breaks "signific/ant") and drop section headers. The sample chunk_by_char uses 150-character chunks with 20 characters of overlap.
Structure-based chunking is cleanest, but only for reliably structured documents. Splitting markdown on \n## headers gives tidy sections. Plain text, PDFs and user uploads often have no markers to split on.
Semantic chunking gives the best chunks at the highest cost. It groups sentences by measured similarity, which the lesson says is expensive and more than most applications need. Sentence-based chunking (5 sentences, 1 sentence of overlap in the example) is offered as a middle ground.
Choose the strategy by document type, then iterate on real data. The lesson recommends structure-based for consistent structure, sentence-based for mixed types, and character-based for code or unknown formats. Start simple and refine after testing.
Claude on Google Cloud: 34-Introducing Retrieval Augmented Generation
Putting a whole large document in the prompt is a poor default. For an 800+ page financial report, the lesson gives three reasons: the text may exceed the hard input limit, Claude gets less effective with very long prompts, and big prompts cost more and run slower.
RAG chunks the document and sends only the relevant pieces. A question about risks pulls in only the Risk Factors chunk. That keeps Claude focused, scales to large or multiple documents, and makes prompts cheaper and faster.
RAG adds engineering work and can drop needed context. It needs a preprocessing step, a way to search for "relevant" chunks, and a choice among many chunking methods. Retrieved chunks can also miss context: Risk Factors alone leaves out the Strategy Outlook section on how the company plans to handle those risks.
Web search is built into Claude; you only supply a schema. The schema has type web_search_20250305, name web_search, and max_uses (5 in the example), which caps how many follow-up searches Claude can run. Claude then decides for itself when to search.
allowed_domains restricts searches to trusted sources. The example limits searches to nih.gov, so health answers come from government sites rather than random fitness blogs.
The structured response is designed for rendering with citations. It contains text blocks, the exact search query used, the search results with titles and URLs, and citations tying statements to source text. The lesson suggests showing the results as a reference list, citations inline, and the cited text highlighted, so users can check Claude's sources.
Claude knows the text editor tool's schema, but you write the implementation. Claude can ask to view files, directories or line ranges, replace text, create files, and insert lines. Your code has to perform each of those operations.
A small, model-specific schema stub turns the tool on. For Haiku 4.5 the stub is type text_editor_20250728 with name str_replace_based_edit_tool, and Claude expands it into the full specification. Version strings for other models are in Anthropic's text editor tool docs.
The tool lets your own app work like an AI code editor. In the example, Claude views main.py, rewrites it with a function that calculates pi to the 5th digit, and creates test.py with unit tests. The lesson pitches it for apps that edit files programmatically or run without a full-featured editor.
Claude on Google Cloud: 31-Tools for structured data
A forced tool call extracts structured data more reliably than prompting. You write a schema for the data you want and force Claude to call it, then read the result from response.content[0].input. No follow-up message is needed. The lesson contrasts this with the simpler prefill-and-stop-sequence approach, which is easier to set up but less reliable.
tool_choice decides whether Claude must call a tool.auto (the default) lets the model decide, any requires some tool, and {"type": "tool", "name": ...} requires a specific one. Extraction uses the last option to guarantee the schema tool is called.
Use prompting for quick jobs and tools for guaranteed structure. The lesson's article example extracts title, author and a list of key insights. It recommends tools whenever reliability matters more than the extra setup.
Claude often makes parallelizable tool calls one at a time. Asked to set two reminders for the same date, it typically calls the tool once, waits for the result, then calls it again, rather than sending two tool use blocks in one message.
A batch tool nudges Claude into grouping its calls. The batch_tool schema takes a list of invocations, each with a tool name and arguments. run_batch runs each one through the normal run_tool router and returns the results together. The lesson openly calls it a workaround that "tricks" Claude.
Batching cuts the round trips to one call and one reply. With the batch tool, both reminders went out in a single call and the results came back in one follow-up, which the lesson says reduces latency.
Once the tool plumbing exists, adding a tool takes three steps. Add its schema to the tools list in run_conversation, add a branch for it in run_tool, and write the function. The reminder system gets three tools: get the current datetime, add a duration (because Claude isn't reliable at date arithmetic), and a placeholder set_reminder.
Claude chains tools across turns to finish a compound request. For "a reminder 177 days after Jan 1st, 2050", it first called add_duration_to_datetime to get June 27, 2050, then set_reminder. Each assistant message pairs a text block explaining the step with a tool use block.
Claude on Google Cloud: 28-Implementing multiple turns
Keep looping until Claude stops asking for tools.run_conversation calls Claude, appends the reply, and stops when stop_reason is anything other than "tool_use". Otherwise it runs the requested tools and sends the results back as a user message.
Every tool use block needs a matching tool result block.run_tools picks out every tool_use block in the reply and builds a result for each, with the same ID in tool_use_id and the output as JSON in content.
Return failed tool calls as results, not as exceptions. If a tool raises, the code still sends back a tool result with "Error: …" as the content and is_error: True, so Claude sees what went wrong.
Route tool names through a separate run_tool function. A dispatcher that maps names to functions lets you add tools without touching the conversation loop.
Claude on Google Cloud: 27-Multi-turn conversations with tools
One question can need several tool calls in sequence. "What day is 103 days from today?" makes Claude call get_current_datetime, then add_duration_to_datetime, before it answers. The application must handle that back-and-forth automatically.
Helper functions must handle whole messages, not just text.add_user_message/add_assistant_message now accept a string, a list of blocks, or a full Message. chat takes a tools list and returns the full message, and text_from_message joins the text blocks for display. The point is to keep every block Claude returns, not just the text.
Call your function with the tool block's input, then return the output. The tool use block's input dict is unpacked with ** into the function. The output goes back in a tool_result block with the matching tool_use_id, the output as a string in content, and an is_error flag.
Matching IDs pair each result with its request, whatever the order. When Claude asks for 10 + 10 and 30 + 30 in separate tool use blocks, the results can come back in either order, because each result carries its request's ID.
Send the tool schema again in the follow-up request. The follow-up carries the full history plus the tool result. Even if Claude won't call the tool again, it needs the schema to understand the tool references in that history.
Claude on Google Cloud: 25-Handling message blocks
A tool-enabled request returns an assistant message with several blocks. Passing schemas in tools can produce a reply with a text block explaining the step and a tool use block. The tool use block holds an ID, the function name, and inputs matching the schema.
Append the entire response content to history, not only the text. Claude keeps no history between calls, so messages.append({"role": "assistant", "content": response.content}) is needed to keep the tool use block for later calls. Helpers that only handle a single text block have to be updated.
A tool spec is a name, a description and a JSON Schema. JSON Schema is an existing data-validation standard that the AI field adopted. The lesson advises descriptions of 3-4 sentences covering what the tool does, when to use it and what it returns, plus a detailed description of each argument.
Have Claude write the schema for you. Paste the function into Claude with Anthropic's tool-use docs attached and ask for a valid schema that follows their best practices. Store it under a function_name_schema variable, optionally wrapped in ToolParam to avoid type errors later.
Tool functions are plain Python that Claude calls for data or actions. The first example is get_current_datetime(date_format="%Y-%m-%d %H:%M:%S"), one of three tools planned for a reminder app, along with adding a duration and setting a reminder.
Validate inputs and raise clear errors, because Claude reads and retries them. Claude sees the exact error text, so a message like "date_format cannot be empty" or "Location cannot be empty" lets it retry with corrected arguments. Descriptive function and parameter names are the other recommended practice.
Setting a reminder from a relative date is harder than it looks. For "Set a reminder for my doctor's appointment. It's a week from Thursday", the lesson says Claude may know the date but not the exact time, doesn't always handle date addition well far into the future, and has no way to set a reminder.
Three custom tools cover those gaps. One gets the current date and time, one adds a duration to a date-time (rather than trusting Claude to work out 379 days from January 13, 1973), and one sets the reminder; they are built one at a time, starting with the date-time tool to teach tool calling.
Without tools Claude is limited to its training data. Asked for the weather in San Francisco, it can only reply that it has no access to up-to-date weather information.
Tool use is a four-step exchange your server mediates. You send the question with instructions on how to get extra data; Claude decides it needs data and requests specifics (e.g. weather for a location); your server fetches it from an API or database; and you send it back so Claude answers from both the question and the fresh data.
Sample input/output pairs show Claude what descriptions struggle to say. One-shot or multi-shot prompting introduces each example ("Here is an example input with an ideal response") and wraps it in <sample_input> and <ideal_output> tags; it is also recommended for complex output formats like JSON or reports.
Examples earn their keep on corner cases such as sarcasm. A tweet calling a film the best since "Plan 9 from Outer Space" reads positive but is negative, so the prompt adds a sarcastic example ("Oh yeah, I really needed a flight delay tonight! Excellent!") labelled Negative.
Take examples from your highest-scoring eval outputs. Input/output pairs that scored 10 in the HTML eval report show Claude what "perfect" looks like for the task.
Explaining why an example is ideal reinforces the wanted qualities. A short note after the ideal output (e.g. well-structured, detailed quantities, aligned with the athlete's goals) helps; the lesson advises starting one-shot and adding examples as eval results warrant.
Claude on Google Cloud: 19-Structure with XML tags
XML tags separate instructions from interpolated data. With large inputs such as 20 pages of sales records, Claude can struggle to tell instructions from data; wrapping the data in a descriptively named tag like <sales_records> marks the boundary and says what the content is.
Tags matter most when similar-looking content is mixed together. In a debugging prompt, <my_code> and <docs> tags let Claude tell the buggy code from the reference documentation instead of guessing.
Even small inputs benefit from grouping. Wrapping the athlete's height, weight, goal and restrictions in <athlete_information> marks them as external input rather than instructions, and the lesson adds that tagged prompts are easier to maintain and debug.
An unspecified prompt leaves the output's shape to chance. A bare request for a short story about a hidden talent could come back at 200 or 2,000 words, with one character or five, as comedy or drama.
Quality guidelines list attributes the output must have. Examples are a length limit (under 1,000 words), a structural requirement and a content requirement; the lesson says these suit almost any prompt.
Process steps make Claude weigh options before answering. Steps such as brainstorming three talents and picking the most interesting suit troubleshooting, decisions and critical thinking; for a sales team's 30% quarterly drop, steps force it to consider market conditions, individual performance, organizational changes and customer feedback.
Adding guidelines roughly doubled the meal-plan eval score. Six guidelines (accurate calories, protein/fat/carb amounts, meal timing, foods fitting restrictions, portions in grams, budget-friendly if mentioned) moved the score from 3.92 to 7.86.
Open the prompt with a plain instruction, not a question. The lesson calls the first line the most important part of a prompt: use simple language, state the task outright and start with an action verb such as "Write", "Create" or "Generate", e.g. "Write three paragraphs about how solar panels work" rather than a rambling question about "those solar panel things".
Rewriting only the opening line lifted the eval score substantially. Replacing "What should this person eat?" with "Generate a one-day meal plan for an athlete that meets their dietary restrictions" raised the meal-plan score from 2.32 to 3.92.
Prompt improvement is an evaluate, change, re-evaluate loop. Set a goal, write an initial prompt, evaluate it, apply a technique, re-evaluate, and repeat the last two, making one change at a time so you know which technique helped.
Start from a deliberately weak baseline. The running example generates a one-day athlete meal plan (inputs such as 180cm, 75kg, "maintain weight and improve power", lactose intolerance) from the prompt "What should this person eat?"; its score of 2.3 out of 10 across 50 test cases, with a 0.0% pass rate, is called a perfect starting point.
Explicit criteria let the grader score consistently. Good output must include a daily calorie total, a macronutrient breakdown, and meals with exact foods, portions and timing.
Read eval reports for patterns, not one-off failures. Per-case outputs, score breakdowns and grader reasoning show what is missing; systematic issues across many cases are what to fix.
Keep evaluator concurrency low to avoid rate limits. Start at 1–3 concurrent requests and raise it only if no rate-limit errors appear.
Syntax validators score output by whether it parses.validate_json (json.loads), validate_python (ast.parse) and validate_regex (re.compile) return 10 on success and 0 on a parse error.
Each test case must declare its expected format. A "format" field such as "python" tells the code grader which validator to use, and the dataset-generation prompt can be updated to emit it.
Stricter instructions and a generic code prefill improve compliance. The prompt adds "Respond only with Python, JSON, or a plain Regex" and "Do not add any comments or commentary or explanation", and prefills "```code" so Claude starts writing raw code without naming the language.
Averaging model and syntax scores weights quality and correctness equally. The final score is (model_score + syntax_score) / 2, with weights adjustable per use case; the lesson says the baseline is neither good nor bad, only a reference for whether prompt changes improve it.
Graders come in three kinds with different tradeoffs. Code graders run programmatic checks (length, required or banned words, JSON/Python/regex syntax, readability); model graders use another API call to judge quality, instruction following, completeness, helpfulness or safety; human graders are the most flexible but time-consuming and tedious.
Define evaluation criteria before building any grader. For the code-generation prompt the criteria are format (only Python, JSON or regex), valid syntax and task following; the first two suit a code grader, the third a model grader.
Ask the model grader for reasoning, not only a score. Requesting 1–3 strengths, 1–3 weaknesses and reasoning alongside a 1–10 score stops it defaulting to middling scores like 6; the grading prompt gives the grader a role, the task, the solution and an output format, parsed via prefill and stop sequence.
Averaging scores gives one number to improve.run_eval reports the mean across test cases, though the lesson concedes model graders can be capricious and may need better guidance.
The eval pipeline is three nested functions.run_prompt merges a test case into the prompt template and calls Claude, run_test_case runs it and grades the output (for now a hard-coded score of 10), and run_eval loops over the dataset collecting results.
Each result records the output, the test case and the score. A full dataset can take around 30 seconds even with Haiku, and outputs come back verbose because the prompt has no formatting instructions yet.
This skeleton is most of an eval pipeline; grading is missing. The lesson says the complexity lies in the details: better prompts, real grading to replace the placeholder, and performance optimizations.
Claude on Google Cloud: 12-Generating test datasets
The example prompt must return bare code, nothing else. For AWS tasks it should produce Python, JSON or a regex, and output should carry no explanations, headers or footers; prompt v1 is just "Please provide a solution to the following task:" followed by the task.
Claude can generate the eval dataset, and a fast model suffices. The lesson suggests Haiku since this is test data, with a generation prompt asking for an array of {"task": ...} objects solvable by a single Python function, JSON object or regex without much code, three objects to start.
Prefill and a stop sequence keep the generated dataset parseable. Prefilling "json" and stopping on "" yields JSON for json.loads, saved to dataset.json; sample tasks included extracting the AWS region from an ARN, a Lambda JSON config, and an S3 bucket-name regex (lowercase, alphanumeric, 3–63 characters).
Claude on Google Cloud: 11-A typical eval workflow
A typical eval is five steps ending in a loop. Draft a prompt, build a dataset, run each input through Claude, grade the outputs, then change the prompt and repeat; many open-source and paid tools exist, but the lesson recommends starting small.
Eval datasets can be written by hand or generated by Claude. Real ones run to tens, hundreds or thousands of records; the example uses three questions ("What's 2+2?", making oatmeal, distance to the Moon).
A grader scores each answer and the scores are averaged. Scores typically run 1–10 (10 perfect, 4 adequate with room to improve); the example's 10, 4 and 9 average to 7.66.
Comparing averages shows whether a prompt change helped. Prompt v1 scored 7.66; v2, which added "Answer the question with ample detail", scored 8.7, which the lesson treats as objective evidence of improvement.
Prompt engineering writes prompts; prompt evaluation measures them. Engineering is the toolkit of techniques such as multishot prompting and XML tags; evaluation is automated testing that checks against expected answers, compares prompt versions and reviews outputs for errors.
Testing a prompt once or a few times is a trap. The instructor says all engineers, themself included, fall into it, and that limited self-testing breaks in production because users supply inputs no one anticipated.
An eval pipeline costs more upfront but replaces guessing with scores. Scoring the prompt and iterating on that data shows whether each change helps or hurts, which the lesson presents as the route to production-ready prompts.
Claude's habit of explaining its work breaks raw-data use cases. In the example AWS EventBridge rule generator, JSON wrapped in markdown fences with headers and footers stops users simply copying the whole output.
Prefill plus a stop sequence returns only the structured content. Prefilling the assistant message with "json" and stopping on "" makes Claude assume it has already opened the block, write the JSON, and halt when it tries to close the fence; json.loads(text.strip()) then cleans and validates it, and the same trick works for Python code or bulleted lists.
Claude on Google Cloud: 08-Controlling model output
A prefilled assistant message steers Claude's answer from its opening words. Claude treats a trailing assistant message as a response it already started and continues exactly where it ends, without repeating it; asked "Is tea or coffee better at breakfast?", it normally gives a balanced answer, but prefilled with "Coffee is better because" it argues for coffee, and "Neither is very good because" yields a contrarian case.
Stop sequences end generation as soon as a given string appears. "Count from 1 to 10" with stop sequence "5" returns "1, 2, 3, 4, " (the stop string is excluded), while ", 5" gives the cleaner "1, 2, 3, 4"; uses include capping list length, stopping at delimiters and keeping formats consistent.
Streaming replaces the dead wait for a complete response. Responses can take 10–30 seconds; with streaming, Claude sends an initial response and then a series of events carrying pieces of text, all within a single request, which the server can forward to the client as they arrive.
Only ContentBlockDelta events carry the generated text. The event sequence is MessageStart, ContentBlockStart, ContentBlockDelta (repeated), ContentBlockStop, MessageDelta and MessageStop; raw streaming is enabled with stream=True on messages.create.
The SDK's stream helper filters to text and assembles the final message.client.messages.stream(...) exposes stream.text_stream for text only, and stream.get_final_message() afterwards returns the complete message for storage or conversation history.
Chunks are not one word each. A chunk can hold several words or whole sentences depending on generation speed; in production the lesson expects chunks forwarded via WebSockets or Server-Sent Events.