From Casual to Capable

This is the design, not the course. It is written for whoever builds the modules, so it argues with itself in places and says plainly where it is uncertain. Learners get the lessons.

Four design premises

These are the load-bearing choices. Everything downstream follows from them, so they're the right thing to argue with first.

1. Diagnosis is the point; the mental model is scaffolding for it. The second objective — learners repair a bad prompt instead of giving up — is the one that actually changes behaviour. But you cannot debug a system you have no model of. So Modules 1–3 teach mechanism, and each one is cashed out as diagnostic leverage in Module 4. No mechanism is taught that doesn't later become a diagnostic move. If a concept can't earn its place that way, it's trivia and it gets cut.

2. Features are taught as answers to problems the mental model predicts. The obvious way to teach Projects, memory and Artifacts is a feature tour. Don't. A feature tour trains learners to ask "what can I do with a Project?" — exactly the tool-first thinking the third objective is trying to break. Instead, Module 2 establishes how information reaches a response, and Module 6 opens with: here are the mechanisms that put it there for you.

3. The course must be able to say "no." A course that only ever demonstrates AI succeeding produces learners who can't tell a fixable prompt from an unfixable task. So the diagnostic clinic in Module 4 contains one genuinely unfixable item, and the capstone accepts "I analysed this and AI is the wrong tool here" as a full-credit answer.

4. No learning objective may depend on Claude making a particular mistake live. New in rev. 3, and it constrains every exercise in the course. The original outline had six demonstrations whose teaching payoff required a stochastic system to misbehave on cue — miscount letters, fabricate a citation, forget a constraint, ignore an instruction not to fabricate. Any one of them may work today. None will work reliably across model releases, and this course is meant to outlive the model it was written against.

The rule in practice: the guaranteed teaching event is always a supplied artifact; the live run is always second and its outcome is always interesting. Learner examines a captured, dated real output that exhibits the failure and works out what's wrong with it — that part cannot break. Then they run it themselves. If today's Claude reproduces the failure, they've confirmed it. If it does better, the debrief has an answer ready: this is a system that improves, which is exactly why you check rather than assume. Either way the objective is met.

This is the premise with the largest production consequence, and it is the reason the review's ordering should be adjusted: it belongs at P0, not P1. The synthetic material set is the longest-lead deliverable in the whole build, and this rule changes what has to be in it — every affected exercise needs a captured "before" artifact that doesn't exist yet. Build the materials first and apply the rule second, and you build them twice.

The tier test — apply to every exercise, during scripting

Premise 4 stated as a check a scriptwriter can actually run. Every exercise in the course is labelled below, and anything that can't be labelled A or B doesn't ship.

The companion copy rule, and it applies to every word of learner-facing text: never assert what Claude will do — say what to look for and why it matters. "Claude will miscount the letters" is a Tier C sentence even inside a Tier A exercise. "Check whether the count is right, and note what you find" is not.

What the tier test is not: an argument for dropping live work. A quiz-only course delivers objective 1 and abandons 2, 3 and 4 — you can test whether someone can classify a broken prompt, but not whether they can repair one, and confidence with Projects is not obtainable by reading about Projects. If the course ever does go assessment-only, the objectives should be rewritten down to match rather than quietly under-delivered.

Sequencing logic

The conceptual spine, in the designer's vocabulary rather than the learner-facing titles. Renaming Module 5 from verification to evidence is not cosmetic: it shifts the module from "catch the robot lying" to "know what any claim rests on and how much being wrong costs," which is a professional literacy skill that stays useful however accurate models get.

• M1 Generation — the root. Everything else is a consequence. First because phrasing sensitivity, fabrication and rerolling are unexplainable without it.
• M2 Available information — requires M1. What can Claude actually reason over for this response, and how did it get there? Supplies M4's two most common failure classes and the entire rationale for M6.
• M3 Specification — requires M1 and M2. Prompting taught before the mental model degrades into template-collecting, which is the habit the course exists to break. Last module where the learner is told what to write.
• M4 Diagnosis — the keystone. Requires M1–M3 in full; each failure class maps to a mechanism from a specific earlier module. Placed at the midpoint deliberately: hardest module, highest drop-off risk, should arrive while motivation is still high.
• M5 Evidence — requires M1 and M4 (so fabrication is already a named failure class). Must precede M6 and M7 because both add ways of bringing information in, and that's meaningless to someone who can't yet ask what a claim rests on.
• M6 Persistence — requires M2. Names the mechanisms M2 described. Before M7 because Projects are the container the file work in M7 lives inside.
• M7 Surfaces — requires M5 and M6. Last teaching module: most interface-heavy, least conceptual, a soft landing before the capstone.
• M8 Design — requires all of it, and the only place the learner starts from a blank page.

One reorder is defensible: moving M6–M7 earlier for a quick win. I'd still resist it. Learners who meet Projects before they understand how information reaches a response use them as folders, and that misuse is hard to undo. If drop-off data says otherwise, the cheaper fix is a five-minute unassessed tour preface, not a resequence.

describe what Claude is doing between pressing enter and seeing text, and predict from that description which kinds of task need extra care.

Core concept

Claude produces its answer sequentially, one chunk of text at a time, each shaped by everything in front of it. Three consequences do most of the explanatory work for the rest of the course:

• Without a source, it's generating rather than looking up. Given no document and no retrieval tool, Claude is producing an answer from what it learned, not consulting an authoritative record. That's the root of fabrication. Note the careful wording — an earlier draft said "it reconstructs, it does not retrieve," which collapses three modules later when Projects retrieve from project knowledge, chat search retrieves past conversations, and web search and connectors retrieve live sources. Claude retrieves constantly. The point is that unaided generation isn't retrieval, and the learner's job is to know which one they're getting.
• Sequential output is not the same as visible reasoning. Claude generates in order, but that does not mean everything it does is present in the words. Work can happen that the final answer doesn't show, and displayed reasoning isn't necessarily a complete account of what produced the answer. What is practically true, and what the learner needs: giving Claude room to work through a hard problem — thinking mode, decomposition, tools, intermediate steps — can improve the result. Teach the lever, not a story about the machinery.
• What it learned has an end date. Claude learned from text up to a point and knows nothing after it — and generally can't tell that it doesn't know. It will answer about last month in exactly the register it answers about a decade ago. Asking the model its own cutoff is itself unreliable, so that isn't the check. Anything time-sensitive needs search or a source you supply.

Plus the small one that explains a daily annoyance: text is handled in chunks, not letters, which is why character-level tasks are shaky. Name them once and move on — these chunks are what everyone else calls tokens, and they're the unit usage limits are counted in, so the word is worth recognising even though the course won't use it again. And output is sampled, not fixed — the same prompt twice can give two different answers, which sets up the reroll trap in Module 4.

say what information is available to Claude for the response it's about to give, name where each piece came from, and take deliberate action when a conversation stops being reliable.

Core concept

Claude can only reason over information made available to the current response. Some of that comes directly from the conversation in front of it. Some is brought in by other machinery: memory, project knowledge, chat search, uploaded files, connectors, web search.

This replaces rev. 2's claim that "anything outside the context window does not exist," which was already false at the time of writing. Claude can search previous chats, memory injects persistent entries, projects retrieve from project knowledge, and long conversations can be automatically compacted — earlier messages summarised so the conversation continues, rather than simply falling off the end. Teaching the absolutist version gives learners a model that Module 6 then contradicts, and being contradicted by a later module is how a course loses trust. The reframe is also a better foundation for M6, which becomes "here is the machinery that makes information available" rather than a rescue from a limitation.

The two things the learner should be able to do:

• Account for what's available. For any response, roughly: what's in this conversation, what did I attach, what might have been brought in, and what did I only assume? That last category is where the surprises live.
• Manage signal, not volume. More material available is not more understanding. An instruction given forty messages ago competes with everything since. A long meandering conversation is mostly noise about the current question.

And the honest version of the old claim: long conversations can become less reliable or less focused. Not monotonically, and automatic context management makes any stronger claim brittle. Teach the recognisable symptom — dropped constraints, drift, self-contradiction — and the cheap repair, which is a fresh chat with a restated brief.

build a prompt from components rather than copying a template, and explain what each component is doing to the output.

Core concept

A prompt is a specification, and vagueness in the spec gets filled in with whatever's most typical. Six components:

• Task — the actual verb. Most weak prompts are vague here and specific everywhere else.
• Context — who it's for, what it's part of, what happens next.
• Input — source material, clearly separated from instructions so the boundary is unambiguous.
• Output shape — length, format, structure.
• Constraints and non-goals — including what not to do, which learners almost never think to state.
• Examples — the highest-leverage component by a wide margin. One example of a good output does more than three paragraphs describing one.

The unifying explanation, from M1: an under-specified prompt leaves Claude to pick something typical, and typical averages out to generic. Every component above narrows the target.

look at a bad output, name which of six failure classes it belongs to, and apply the matching repair — instead of rerolling, rewriting at random, or giving up.

Core concept

The keystone module. Bad output is not one thing and the repairs are not interchangeable.

Renamed from "task too big" on review, and the reviewer was right. "Too big" names a fixed capability boundary while the repair column immediately says it isn't one — the label was arguing against its own row. "Insufficiently decomposed" points at the fix.

Three habits taught alongside the taxonomy:

• The reroll trap. Regenerating without changing anything draws again from the same distribution. If the prompt is the problem, every reroll is also the problem. The single most common wasted action by casual users.
• Ask Claude to diagnose itself — then treat the answer as a hypothesis. "What in my prompt led you to produce that?" is a genuinely useful move that almost nobody makes. But Claude doesn't have privileged, reliable introspective access to why it generated something, and its account of its own reasoning isn't a log of what actually happened. So: ask for a diagnosis, get a hypothesis, then test it. Rev. 2 taught the technique with the wrong epistemics attached, which was quietly inconsistent with everything else the course teaches about taking Claude's word for things.
• Some failures are a settings problem, not a prompt problem. A shallow answer to a genuinely hard task is sometimes fixed by letting Claude work harder rather than by rewriting anything. Named here as a seventh option and cashed out in Module 7 — deliberately deferred, because a learner who reaches for a settings change before checking their specification has learned the wrong reflex.

for any claim in an output, say what it rests on, how to inspect that basis, and how much it matters if it's wrong.

Core concept

Reframed on review from verification to evidence, and the reframe is the improvement. The old module was organised around catching the model lying, which dates badly as models improve. This one is organised around a question that stays useful regardless: what is this claim based on?

Two independent questions, which rev. 2 collapsed into one and shouldn't have:

Column A is a traceability ordering, not an accuracy ordering, and rev. 2 wrongly implied otherwise. A document you uploaded can be outdated, wrong, incomplete, adversarial, or simply the wrong document — and a retrieved primary source from a statistical agency may be far more trustworthy than a PDF someone emailed you. The two questions are orthogonal and both have to be asked.

Which yields the sentence the module exists to install:

Grounded does not mean true. Grounded means you have something concrete to inspect.

Then triage, because effort has to be proportional: risk is roughly cost of being wrong × how traceable the claim is. The reliably high-attention zones, taught as a checkable list: specific numbers, citations and URLs, direct quotes, names and dates, anything legal/medical/financial, recent events, and anything about the learner's own organisation.

And the behavioural rule, stated as behaviour rather than as an empirical absolute: do not use confident tone as evidence of accuracy. Claude writes an unsupported claim in the same register as a well-supported one. Most people are unconsciously reading prose style as a confidence signal, and the fix is a habit, not a belief about what tone does or doesn't correlate with.

choose the right scope for a piece of persistent context, and set up a Project that makes a recurring task meaningfully faster.

Core concept

Calls back to M2: information has to be made available to a response, and typing it every time doesn't scale. These features do it for you. Teach them as scopes, not as boxes — which is a rev. 3 correction, because the tidy three-bucket taxonomy is no longer accurate:

• Instructions for Claude (Settings → Instructions for Claude) — account-wide, always on. About you: your role, your register, how you want to be spoken to.
• Projects — project instructions plus project knowledge, scoped to one body of work, available to every chat in that project. Large knowledge bases are handled by retrieval rather than by holding everything at once, so "will it all fit?" is not the learner's problem to solve.
• Memory (Settings → Memory → Generate memory from chats) — builds itself from conversations as individual entries, organised into categories, updated as you go. Pausable, resettable, exportable, inspectable, and bypassed entirely by an incognito chat.

Why "scopes" and not "boxes." Memory is not a single account-wide store: each project has its own separate memory space and its own project summary, kept apart from other projects and from non-project chats. So "Project" and "Memory" are not parallel alternatives — memory has a project scope. Chat search adds another retrieval route with its own boundaries (all chats outside projects; within a project, that project only). The honest teaching is a single question — how widely should this apply? — answered along a scope gradient, rather than three tidy containers a learner will later find leaking into each other.

The retained decision rule, reworded for scope: true about me everywhere → Instructions. True about this body of work → that Project. Happy for it to accumulate on its own → Memory, at whichever scope you're working in.

get source material into Claude, judge how completely it was actually read, produce something in an Artifact that survives outside the conversation, and set how hard Claude works on a task.

Core concept

• In — files. Documents, spreadsheets, PDFs, images. Makes claims traceable to something you can inspect (M5, column A). Taught with its processing rules attached, not as an afterthought — see the misconception below, which is now the strongest concrete material in the module.
• Out — Artifacts. Triggered when content is substantial and self-contained and you'd plausibly want it outside the chat. Two capabilities casual users miss: iterating in place rather than regenerating, and Publish, which produces a link anyone can open without an account — worth stating plainly, because "publish" means publicly reachable by anyone holding the link.
• Alongside — branching. Editing an earlier message creates another version of the conversation with its own artifacts. Reclassified on review: this is a conversation capability that happens to be useful while developing an Artifact, not one of the Artifact's own features. Small cleanup, but the old grouping taught a wrong mental model of where the feature lives.
• Both — connectors. Google Drive, Gmail, Calendar. Claude can bring a connected app into a conversation when it fits what you're asking. Softened on review from "only when a request actually requires it" — that promised deterministic routing the docs don't claim, and over-promising precision about when a tool fires is a poor lesson in a course about knowing what your output rests on. Docs pulled from Drive stay synced to the current version. On Pro you connect these yourself.

And the dials underneath — how hard Claude works

Clicking the model name opens three separate controls, and casual users almost never touch any of them. This pays off Module 4's seventh repair and closes the loop opened in Module 1.

• Model. The default handles most work; step up for genuinely hard analysis. Teach the dial, never the lineup — model names change often enough that hard-coding them guarantees the module rots.
• Effort. A control for how much work Claude puts into a response. More effort for harder or correctness-critical work, at the cost of time and usage; less for routine work. Teach the trade, not the ladder — the tiers have names and the names will change. Do still say that some options exist for long-running coding and agentic tasks and are out of scope here, without naming which: learners will see options in the menu they don't need, and "here's the part you can ignore, and why" is itself the skill.
• Thinking. Turn it on for anything multi-step or worth getting right. Frame it with the Module 1 callback: remember the arithmetic that improved when Claude was given room to work through it? This is that, as a setting. Thinking and effort are independent and combine freely.

Deliberately deferred from Module 4. A learner who reaches for max effort before checking whether their prompt was under-specified has swapped a diagnostic habit for a dial — the exact behaviour Module 4 exists to prevent.

start from a real work problem, decide honestly whether Claude fits it, and if so build, test and document a working setup — with no template supplied at any point.

The open prompt

Pick a task you personally did more than three times in the last month and did not enjoy. Do not pick a task because it sounds like a good AI task. Pick it because it is tedious, and then find out whether AI helps. Describe its structure in full. Use your own material only if you're free to — otherwise take the supplied synthetic analogue, which is built to the same shape and costs you nothing.

The second sentence is the whole capstone. Left off, roughly everyone submits summarisation or email drafting and the course has assessed template-matching under another name. Constraining the selection rather than the solution is what forces problem-first reasoning.

The seven-step design process

This process — not any individual module — is the durable artifact of the course. Ship it as a reference card, alongside Module 4's failure taxonomy.

1. Describe the task as it exists today. Inputs, outputs, who consumes it, what "good" looks like, how you'd know it had gone wrong. Structure, not contents.
2. Run the fit test — argue both sides. Anti-criteria supplied: tasks needing facts Claude can't reach; tasks where a wrong answer is expensive and hard to detect; tasks that are mostly judgement you can't articulate; tasks where checking costs more than doing. "This doesn't fit" is a full-credit answer if the reasoning holds — the learner then picks a second task and continues.
3. Decide the shape. One-off chat or a Project? What should the output rest on (M5)? At what scope should context persist (M6)? Does the output want to be an Artifact (M7)?
4. Build it. Instructions, knowledge, prompt.
5. Write the test set before looking at any output. Three cases including one deliberately hard or edge case, pass criteria fixed in advance. Writing criteria after seeing output is how people talk themselves into mediocre results, and naming that trap is part of the instruction.
6. Run, diagnose, iterate — at least twice, documented. Every failure classified with the Module 4 taxonomy and repaired accordingly. A capstone with no documented iteration is incomplete regardless of how good the output looks, because the iteration is the skill being assessed.
7. Write the handoff note. What this is for, what it's bad at, what a user must check. Forcing articulation of limits is the cleanest proof that Modules 4 and 5 landed.

Assessment and completion, with no one grading

1. Auto-graded knowledge checks — per module

Six to eight items, 80% to pass, unlimited retries from a shuffled pool so retrying isn't memorising. The critical rule: wrong answers return a mechanism-level explanation, not "incorrect." With no instructor, the quiz is the only thing that can catch a misconception at the moment it's exposed, so it must teach rather than merely measure. Budget four distractor explanations per item — the most underestimated cost in the build.

2. Behavioural gates — per hands-on

Binary, self-evident, hard to fool yourself on. "Your project instructions contain an output-format constraint — yes or no." These carry more weight than any confidence rating, because the learner checks a fact about an object rather than rating a feeling. Never ask "do you feel confident with Projects?" — the answer is uncorrelated with anything.

3. Claude as the capstone grader

The learner pastes their design record into a supplied grading prompt that scores against published criteria and returns specific gaps. Defensible rather than a cop-out because the criteria are public and auditable, and because by Module 5 the learner has been taught not to take Claude's judgement on trust. The instruction should say so outright — challenge this grade; if you think it's wrong, argue with it and see if it holds. The assessment becomes one more repetition of the skill. Note this also works on a structure-only design record, so it never requires real content.

4. Spaced, interleaved retrieval — day 7 and day 30

Two short cumulative checks, drawing across all modules and deliberately interleaved — a diagnosis item, then a scope item, then an evidence item — rather than blocked by module. Blocked practice inflates in-the-moment performance and does much less for retention. The only element targeting durable recall rather than course-completion, and the cheapest thing here to build.

Completion criteria

• All eight module checks passed at ≥80%.
• All behavioural gates checked.
• Capstone design record covers all seven steps, with at least two documented iterations and a handoff note naming at least two real limitations.
• Self-graded capstone at or above threshold on every criterion, with no criterion at zero — an aggregate alone lets someone pass having skipped evaluation entirely, which is the step most likely to be skipped.

Day-7 and day-30 checks are reported but deliberately don't gate the certificate. Gating them creates an incentive to defer completion, and the retention value doesn't depend on compulsion.

Before the build starts

1. The synthetic material set is the critical path, and premise 4 just enlarged it. Every affected exercise now needs a captured, dated "before" artifact that doesn't exist yet: a fabricated-citation response, a 20-turn drifting transcript, a step-by-step arithmetic pair, an ignored-instruction example. These carry the pedagogy; too clean and every exercise succeeds and nothing is learned. Scope as a named deliverable with its own review pass — and build it after premise 4 is settled, not before.
2. Volatile specifics are out; locations stay in. The test applied throughout: does the learner need this to take an action, or only to feel informed? Page thresholds, effort-tier names and model lineups are informed-only, and they're cut — a named number fails twice when it changes, since the number is wrong and the habit it built was wrong. What stays is where things live (Settings → Memory, the project knowledge panel, the Publish button, the model-name menu), because objective 4 is unreachable without it. That's roughly half a dozen interface locations across the whole course — small enough to be a pre-cohort checklist rather than a versioned specifics file with an owner. Keep screenshots in one replaceable asset set with capture dates, and prefer the written path in body copy so the text survives a UI change even when the image doesn't.
3. Module 5 still needs the most review, though less than before. The evidence reframe means it leans less on an authored account of hallucination mechanics and more on a question anyone can apply, which is more robust. Still: get it read by someone who understands the mechanism and someone who represents the audience.
4. Market it as 5–6 hours, not 5. Designed instruction is ~285–300 minutes, but that excludes quiz retries, setup friction, response latency, project creation, publishing and reading feedback. Under-promising learner time in an async course is a completion risk, not a marketing win.