Search a lesson

173 lessons.

Chat, Cowork, Claude Code, three tools, three usesChoosing the right way in
The chat answers, Cowork acts on your files, and Claude Code works on code: three interfaces for the same family of models. What sets them apart is the tools the model can call and the context you give it. Code work goes to Claude Code, knowledge work to Cowork.
Cowork, the default mode for a non technical userChoosing the right way in
On an account that has not yet moved to the new unified experience, Cowork acts directly on connected folders and is best split into small passes rather than one giant job; once the account has moved, the same actions happen from the same conversation as the chat, with a single approval setting for the whole conversation.
Setting up the computer for long sessionsChoosing the right way in
For a long task that touches your local files, prevent your computer's automatic sleep and switch on the Claude application's notifications. Claude Desktop must then stay open, awake and connected: if the computer falls asleep, the task stops with no sign other than the missing result. A fully remote scheduled task does not need it.
Chat and Cowork are now one conversationChoosing the right way in
Since chat and Cowork merged into a single conversation, you no longer pick a tool before writing: Claude decides for itself whether to answer or to act, and a single setting, Auto or Manual, replaces the old choices specific to each tool.
Understanding the token and the context windowNever running out of tokens
Claude reads tokens, small fragments of text, and the context window is the space that holds everything it can see at once: your message, the conversation history and the attached files. Reopening an old session reloads that whole history with every question, even a short one, making it slower and heavier on quota.
What to do when the limit is reachedNever running out of tokens
Once the limit is reached, sending new messages is impossible until something unblocks it: waiting for the counter to reset, changing plan, or buying usage credits. Only waiting is free, and the only useful preparation is knowing in advance who to turn to within your organisation.
The right habits for savingNever running out of tokens
To save quota, if the task is unrelated to the previous one, open a new session attached to the same project rather than extending a session from one day to the next. An extended session rereads its whole history with every question, while the new one starts from a short base and finds the project's files and instruction.
The project, a container for contextKeeping the thread from day to day
A project brings together, in one permanent place, reference files, an instruction written once, and the sessions opened inside it. A conversation opened outside any project keeps none of these three elements beyond its own window: closing it amounts to emptying it. A task that returns with the same files belongs in a project.
Turning on memory, distinct from historyKeeping the thread from day to day
Memory is not history: history keeps every conversation as it unfolded, while memory keeps only a selection and reuses it in a following session. It is on by default on personal accounts and off by default on organisation accounts, where you should first check that it has been switched on.
Resuming a session without losing everythingKeeping the thread from day to day
Open a fresh session inside the same project and explicitly ask it to pick up the thread. The project's files and instruction stay in place, but the detail of the previous conversation does not follow: whatever is written nowhere in the project will not come back unless you hand it back.
What Cowork sees and what it does not seePutting Claude to work on real files
Cowork only modifies files in the folders you have connected, but it sees more than files: with your authorisation it takes screenshots of your screen, and from Chrome's side panel it sees the displayed page. Close or hide whatever has nothing to do with the task.
Working on a copy, never on the originalPutting Claude to work on real files
Work on a copy, because Claude modifies the file itself, where it sits, and creates no backup behind the scenes. A rewrite does not require the confirmation a deletion does, so a silent error becomes more likely. Duplicate any document that must remain a reference before handing it to Claude.
Skills and plugins, specialisation on demandPutting Claude to work on real files
A skill is a specialisation Claude loads for a specific domain or a repeated way of doing something, written once. A plugin bundles several skills into a single installable package. Read the description before activating either: it is the only place where its author states what it does.
Connectors, a direct link to a piece of softwarePutting Claude to work on real files
A connector is an authenticated link between Claude and an external service, such as a mailbox, a calendar or a file space. Authorising it commits you beyond the current conversation, right up to your scheduled tasks, and on an organisation account an administrator sets the list of connectors offered.
What calls for particular caution before having a document processedPersonal data, the mandatory caution
Identity, health, personal situation and access secrets call for particular caution before having a document processed. Replacing a name with a number is not enough while a correspondence table exists somewhere. A secret that passes through a conversation, even briefly, must be treated as already compromised.
What the organisation account guarantees, and what it does not guaranteePersonal data, the mandatory caution
On an organisation account, the content of conversations is not used to train the models, unless the organisation itself joins the development partnership programme. This guarantee answers only the question of training: the organisation remains solely responsible for the processing, and an individual account follows different terms.
Handling a first real case from start to finishInto practice, and finding your own way
Handle a real case in your project, in small passes, and treat the deliverable as settled only once you have reread it yourself. The end-of-task message and a clean layout prove nothing: count the items, compare them with the source, and find every numerical value in the original document.
The reference glossaryInto practice, and finding your own way
This glossary gathers the words that keep coming up in the course: agent, token, context window, project, skill, plugin, connector, scheduled task, processor. They are enough to phrase a request and describe a blocker to someone. Keep the sheet open during your first week rather than memorising it all at once.
Predicting the next word, nothing moreWhat a language model is, without the jargon
A language model does only one thing: predict the most probable fragment of text to follow what it has already read, and a made-up answer comes out of the same calculation as an accurate one, with no internal signal telling them apart.
The token and the window, what the model actually seesWhat a language model is, without the jargon
The model sees tokens stacked inside a window with a fixed ceiling, not whole words taken one by one, and a conversation approaching that ceiling changes content before it even reaches its maximum cost, since Claude then summarises the oldest exchanges.
The myth of the magic settingWhat a language model is, without the jargon
Two different answers to the same question do not signal a fault: they come from an internal setting, temperature, which adjusts the risk taken in choosing the next word, and this setting does not fix a poorly phrased request, the request itself can.
One family of models, a choice between speed and depthWhat a language model is, without the jargon
The Claude models, Fable, Opus, Sonnet and Haiku, come out of the same base training and are mainly distinguished by one trade-off: how fast the answer comes against how deep the reasoning goes. Fast models suit short, repeated tasks, deeper ones suit files that need cross checking, and the price follows the same axis.
Meaning without a dictionary, and why order mattersWhat a language model is, without the jargon
Claude opens no dictionary, it associates each word with words of similar meaning and weighs each one against all the others at the moment of answering, which means the place of an instruction in the message changes its real weight in the answer.
How Claude learned to answer, and up to whenWhat a language model is, without the jargon
Claude goes through three training stages before any conversation, a broad reading of the world, an adjustment into a useful assistant, then self correction grounded in written principles, and the resulting knowledge stops at a date that varies by model.
The three blocks of a requestWriting a request that works
A request that works separates three blocks: what Claude must be, what has already been said, and what is being asked now. For behaviour beyond the minimum, ask for it explicitly rather than counting on the model to guess. With a project, the role is set once, in its instructions.
Being clear, direct, and giving the whyWriting a request that works
Claude behaves like a brilliant new employee who knows neither your habits nor your sector: be precise and give the why, not just the task. Name who will read or hear the answer too. To test clarity, show your request to a colleague with no context: if they are lost, Claude will be too.
Assigning a roleWriting a request that works
A single role sentence placed at the start of a conversation or a project shapes Claude's tone, vocabulary and priorities more effectively than a long list of scattered instructions. A useful role names a specialism, an audience and at least one formal constraint, rather than a title that is too general.
Separating data from instructionsWriting a request that works
Mixing instructions and data in a single block forces Claude to guess where the instruction stops: a sentence from the pasted text can pass for an instruction. Wrap each type of content in an explicit boundary, a tag, a Markdown heading or a marking line, and check that every opened tag finds its closing match.
Formatting the output and speaking on Claude's behalfWriting a request that works
Specify the format by saying what the response should contain rather than what it should not contain. To have it start with the result, name the first element expected: this replaces the old prefilling, which meant writing the start of Claude's response yourself and no longer works on recent Claude models.
Making Claude reason before concludingWriting a request that works
Asking Claude to write out its reasoning before its conclusion improves accuracy on multi-step questions, whether that reasoning is invited by a sentence in the request or is already active as a standalone mode, and both versions consume extra tokens.
Showing the target rather than forbiddingWriting a request that works
Three to five input to output examples anchor a format or a tone better than a long list of rules, and a positive instruction gives a clear target where a purely negative instruction leaves Claude guessing what to replace it with.
Composing a complex request without inventingWriting a request that works
A complex request is composed piece by piece, who Claude should be, the context, the data to process, what is being asked, an example, the expected format, then a final line that allows Claude to say I do not know rather than invent an answer.
Making a working request last and reusing itWriting a request that works
Keep a request that works and adjust it in small touches, one part at a time, rather than rewriting it from scratch. Place a long document right at the top of the request, before the question. Then fix the request into a reusable template where only what changes from one task to the next is replaced.
A green result proves nothing until it has itself been provenChecking what it gives back
A check that has never been made to fail by a case it is actually supposed to catch has proven nothing, in the strict sense that proving requires a precise command to have run and its output to have been read: a broken detector returns zero problems, and that reads exactly like a success.
Test the checker before trusting its verdictChecking what it gives back
A check that returns a plausible number may not return a correct one, and the gap almost never announces itself. Test the script before trusting its verdict: give it a fabricated input it must flag and a clean input it must not flag, covering the real quirks of your ground.
The remedy against invention can invent tooChecking what it gives back
A verification device is a deliverable like any other, produced by the same kind of mechanism as what it checks. Rerunning the same check does not make it independent, since a deterministic bug repeats identically: only a genuinely different method, one that could fail another way, counts as proof.
Where you look determines what you findChecking what it gives back
A review pointed at the latest change tells you where you looked, never where the defects actually are: without having examined the rest with the same care, no conclusion about the relative danger of recent code versus old code holds up.
A very rigorous review can still see nothingChecking what it gives back
A review, however disciplined, only judges what already exists: a screen never built or a function never written appears nowhere in its scope. What fills that gap is a different question, asked outside the code being reviewed, such as a complete user path handed to real use.
Proven, or simply not yet refutedChecking what it gives back
Proven means you have run a precise command and can cite its output. Not yet refuted means only that nothing has caught a problem so far, a far weaker claim. A green preview or an absence of console errors therefore does not show that no defect exists.
A form check never sees a false valueChecking what it gives back
An automated check almost always verifies form and very rarely truth: a valid file, a correct encoding or a keyword on the page can all sit beside a false number. Validating a screenshot of the page that generates the document likewise does not prove what the person actually opens.
Reopen every source before believing itChecking what it gives back
A research agent reports what an index shows, not what a live page contains today, and presents a dead link with the same confidence as a live one: any source meant to support a conclusion gets reopened before being cited.
Count the whole population, and name the measure for what it capturesChecking what it gives back
Measuring the few cases noticed by chance rather than the whole population produces a conclusion that is confident and yet wrong, and that same conclusion stays wrong if the name given to the result says something other than what the instrument actually captured.
Three agents agree, one single sourceChecking what it gives back
Agents that return the same conclusion while citing the same page confirm nothing: the team holds one source, cited several times. Agreement is worth what the distinct sources behind it are worth, and a different address, or a copy under another domain, is not yet an independent source.
What a check exempts disappears from its outputChecking what it gives back
What a check exempts disappears from its output: the scope is decided once, then nobody rereads it. A compliant verdict covers the folder minus the exempted part, which can grow unnoticed. Give that part its own limit that weighs on the verdict; displaying its size is not enough.
Chaining promptsTechniques that change the result
Chaining means breaking a complex task into several short messages, where the answer to one serves as raw material for the next. Each link becomes a point where you can read, correct, or stop the chain before continuing. The simplest pattern runs draft, review, correction.
Giving Claude handsTechniques that change the result
Claude acts beyond text by going through a tool, a function described by a name, an explanation and the shape of its arguments. It chooses to call it and proposes arguments, but execution always falls to something other than Claude, your application or certain Anthropic servers. The more precise the description, the closer the arguments come to what was intended.
Composing a system prompt from several sourcesTechniques that change the result
Take a rule from elsewhere and rewrite it in your own words for your own situation, rather than copying it as is. When an imported rule contradicts one already in place, the rule of the system prompt's owner has priority. Then check that the rephrased rule still triggers the expected behaviour.
Citing sources and not beating about the bushTechniques that change the result
A useful citation fits in an inline bracket right after the sentence it proves, one source per bracket, with no separate section at the end of the message, and a direct answer states the fact instead of announcing it and then closing with a polite question.
Structured outputs and guardrailsTechniques that change the result
Forcing an exact schema on an output and checking that output before using it are two halves of the same reflex, one forces the form upstream, the other controls it downstream, and both matter more when the action that follows cannot be undone.
Checking a prompt the way you check a resultTechniques that change the result
You check a prompt with an eval, a fixed set of test cases written in advance that scores it automatically, not on a few examples tried by chance. A prompt improved by asking Claude (meta-prompting) stays a draft and goes through the same set of cases. Retest on exactly the same set, before and after.
Asking several times, and contradicting yourselfTechniques that change the result
Asking for several independent answers and keeping the majority filters out the noise of a single answer, and asking Claude to play devil's advocate against its own answer finds errors a single pass misses, provided you always run a final synthesis to sort the valid objections from the noise.
The premortem: assume the plan has already failedTechniques that change the result
The premortem reverses the question. Instead of asking whether the plan is good, which invites looking for reasons to say yes, you state that it has already failed and ask for the autopsy. It brings out the causes of failure, which remain hypotheses to check.
The model landscape, one family of predictorsChoosing your model and your tool
Claude, GPT and Gemini rest on the same basic training principle, which Anthropic describes for Claude as predicting the next word. Open-weight models share this architecture. A prompt technique learned on Claude therefore often works almost as it stands elsewhere, even though the context window, data handling and tools differ.
Route by task, not by brandChoosing your model and your tool
Choose a model by what the task requires: capability, speed, cost and tuning effort, not out of habit. Two questions place a task: routine or new, low stakes or high. Tuning the prompt, with a more precise role or better-set context, often changes the result more than switching models does.
Composing a system prompt across several providersChoosing your model and your tool
When a prompt has to work across several providers, take each one's strongest rule, merge them without contradiction, and rules written by the prompt's owner generally outrank a provider's defaults, except when they would conflict with the safety limits that provider sets for itself.
Local model, custom-built, or simply a better promptChoosing your model and your tool
For a small organisation, in the vast majority of cases, a better-written prompt solves the problem faster. A local open-weight model involves no cost charged per call and sends no data out, but it takes hardware. A custom-built model costs a lot to construct and is only worth it at very high volume or for a fixed format.
Low, medium, high, xhigh, max: choosing your effort levelChoosing your model and your tool
Start from the level marked Default, go up one notch if the answer seems superficial, go down one notch if it drags on a simple question. The effort level sets how much work Claude puts in before answering: higher effort gives more thorough answers, but they take longer and use up your plan faster.
Opening Cowork and setting up your first workspaceCowork, the digital colleague
Cowork is Anthropic's desktop agent: it requires a paid plan and, to reach your local files, the Claude Desktop application open and connected. Its workspace is a project, which groups attached folders, instructions written once and for all, and a memory that belongs to it.
What Cowork can reach, and what it must never touchCowork, the digital colleague
Cowork's access breaks down into three distinct layers, connected folders, direct use of your applications and screen, and an isolated network that blocks internal addresses by default; in all three cases, permanently deleting a file always asks for your confirmation.
Writing a brief Cowork can execute, then reading its plan before it startsCowork, the digital colleague
A good brief names a result, its source, its destination and the workspace concerned, as if for a colleague starting that same day; Cowork answers with a plan that needs reading, because a wrong assumption spotted before execution is corrected at no cost, spotted after it can mean undoing writes already made.
Choosing your approval level, step by stepCowork, the digital colleague
On an account not yet moved to the new experience, the approval modes decide who controls a Cowork action before it runs: you (Manual), Claude itself (Automatic), nobody (No approval). Switch to Manual for sensitive files, accounts or sites, a tool used for the first time, or a mistake that would be hard to undo.
Rebuilding a real spreadsheet or report, not a draft to fixCowork, the digital colleague
Cowork returns a finished file, a workbook whose formulas genuinely recalculate, a laid out slideshow or a formatted document, not raw text to lay out yourself. Name the exact structure expected or supply a template to copy. A correct figure in a cell does not prove the formula: click on the cell and read it.
Connectors: what they actually read and writeCowork, the digital colleague
A connector's capabilities are checked service by service: they should never be guessed by resemblance to another tool from the same vendor. The Gmail connector can send, reply to and forward messages, with approval requested by default. The Outlook one depends on what an administrator of the account has switched on across the whole organisation.
Scheduled task or Computer Use: the order Cowork triesCowork, the digital colleague
Cowork tries a connector first, then the desktop application's browser, and direct control of the screen only as a last resort, always in the same order. A scheduled task triggers this same cascade at the set time, with no human watching the screen at the moment it runs.
Cowork everywhere, who can do what, and the trail left behindCowork, the digital colleague
Cowork runs on desktop, web and mobile, with cloud sessions that keep running with no device switched on. Access depends on the plan: on Enterprise, an administrator must switch it on. On Team and Enterprise, a technical export, limited by default to metadata, exists only if an administrator has set up a collector; it does not cover a local session.
Recipe: sorting your mail without ever sending anything by mistakeRecipes for everyday work
A prompt injection attack requires two conditions at once, reading untrusted content and being able to act on it: for mail, the real barrier is no longer an inability to send, it lies in the approval setting in force on your workspace, to be checked before trusting your own proofreading alone.
Recipe: turning scattered notes into a clean document or spreadsheetRecipes for everyday work
Cowork produces structured documents and spreadsheets with working formulas from raw notes: on a large batch, explicitly asking for a plan and then each section separately gives a more reliable result than a single big instruction launched over the whole folder.
Recipe: building a text in separate steps rather than in one goRecipes for everyday work
An important text is broken into named steps, each with a single role, an approved plan first, then the drafting, then aligning the tone as a step in its own right, then a reread handed to an editor role rather than a simple request to rewrite.
Recipe: organising the team's shared memory without duplicating itRecipes for everyday work
Shared memory does not improve by adding files: it improves when it links what already exists and flags what is repeated. Have Cowork compare the content of documents rather than their titles, note a link to the related document rather than merging, and keep a one page contents list up to date.
Recipe: producing the same document in several languages without it divergingRecipes for everyday work
Designate one version as the source and lock it, then ask for each language directly from it, never from a translation. Then compare the key figures and technical terms across versions. Note in each file the source version it came from, so that a correction is not forgotten in one language.
Recipe: sharing a document as a single file that opens everywhereRecipes for everyday work
Produce a single self-contained file that embeds everything it displays, text, images and formatting, with no outside link or font. Then open it offline before sending: a missing image or broken formatting reveals a dependency. The format alone guarantees nothing.
Claude Docs: a document your team edits with ClaudeRecipes for everyday work
Claude Docs is for writing living documents with Claude and your team. People with editor access work on the document at the same time as you, and each change appears in real time, attributed to its author. For a precise touch-up, comment on a passage and mention @Claude, which replies in the thread.
Claude Code and the agent loopFundamentals and the agent loop
The agent loop is the cycle in which Claude Code thinks about what action to take, calls a real tool, then observes what the tool produced before deciding what comes next. It does not return a single reply: the loop repeats as many times as needed, until the goal is reached. Every reflection and observation displays as it happens.
CLAUDE.md, the project's memoryFundamentals and the agent loop
CLAUDE.md is a text file at the root of a repository, which Claude Code reads automatically at the start of every session opened on it. Its rules are read as context, with no strict guarantee of compliance. To block an action whatever Claude decides, a PreToolUse hook is needed.
The essential slash commandsFundamentals and the agent loop
A few slash commands manage the project's memory, reset the context or summarise it, and inspect what is loaded in the session, without ever touching the repository's code. /clear wipes everything, /compact keeps a summary of what has just been done, useful in the middle of a long task.
Permissions and plan modeFundamentals and the agent loop
The permission mode decides which actions Claude Code carries out without asking: since September 2026, an interactive terminal or VS Code session with no configured mode starts in auto mode, on every plan, rather than default mode, and auto mode acts broadly under the background watch of a second model.
Interrupting and redirecting mid-taskFundamentals and the agent loop
Esc interrupts the current turn, reflection or tool call, without losing the accumulated context; then type the correction to carry on from the same base. Ctrl+C depends on what is running in the terminal at that moment and, pressed a second time when nothing is running, ends the Claude Code session itself.
Pointing to files with @Fundamentals and the agent loop
The @ symbol, typed in the input field, opens a menu that points to a real file or folder on disk, filters the suggestions as you type, and clearly separates the moment a path is inserted into the message from the moment that message is sent.
Running shell commandsFundamentals and the agent loop
The Bash tool runs a real shell command on your machine, not a simulation, then Claude Code reads the standard output and error output to continue from what was actually produced. A permission prompt appears before every new command, except for a built in set of read only commands.
Reading and approving a diffFundamentals and the agent loop
A diff is read line by line before being approved: it marks with a minus what disappears from the file and with a plus what is added, and a surgical modification is recognisable by how short these two blocks are. Approval is done through a menu of named options, not a free keystroke.
The task list and the status lineFundamentals and the agent loop
On the most recent models, the task list stays empty by default, with Claude managing multi step work without exposing it, while a status line configured by a script shows the active model, the context window and the session cost live.
The map of a structured setupA structured installation
A Claude Code setup that holds up over time reads as a map of seven elements, the engine, the CLAUDE.md constitution, file based memory, the git transport, hooks, skills and the scheduled heartbeat, rather than as a pile of settings with no plan.
Installing, signing in and the first launchA structured installation
Claude Code installs through five commands, but only the two native ones (curl, irm) update themselves. Sign in with your subscription: an API key already in the environment is not used silently, and Claude Code asks you to approve it. Then run claude doctor, which checks the installation and proposes a fix only after reporting.
The global CLAUDE.md, a constitutionA structured installation
The global CLAUDE.md now targets a length in lines rather than in kilobytes, and it does not override the other CLAUDE.md files by overwriting them: the four scopes, managed, user, project, local, are concatenated in the context from the broadest to the most specific.
Wiring file based memory to gitA structured installation
A memory folder versioned by git, with a private remote and a merge rule that keeps both contents rather than forcing one over the other, remains a technique to build yourself, distinct from the native automatic memory, which never leaves the local machine.
Hooks and heartbeatA structured installation
Lifecycle events trigger hooks on three distinct cadences, SessionStart and SessionEnd form the natural pair for automating the memory protocol, and nightly consolidation remains an operating system scheduled task you build yourself, not a Claude Code mechanism documented under that name.
Curating your skills and closing out the setupA structured installation
A skill is installed one at a time, against a need you have already encountered, never in a batch, and closing out the setup means proving each of the module's seven map elements with an executable action rather than assuming it is in place.
AGENTS.md: when Claude Code reads it, and how to checkA structured installation
With the default setting, Claude Code reads AGENTS.md only when no CLAUDE.md, CLAUDE.local.md included, takes its place in the working folder or above. The /config panel says what is requested, not what was read: check it at session start, from the line shown in the conversation or with the /memory command.
Your instructions age with the modelsA structured installation
Your instructions age because a rule born from one model's flaw stays in place when the model changes: it is not wrong, it becomes unnecessary, and the model keeps reading it every session. The /doctor prompt-audit command rereads your instruction files and spots those written for older models.
Skills: teaching Claude a workflowExtending: skills, MCP, subagents, hooks, plugins
A skill teaches Claude a workflow by gathering a complete operating procedure into a single SKILL.md file. Claude triggers it in two ways: a slash command bearing the folder's name, or automatically when its description matches the request. Once loaded, its text is added to the turn as additional instructions.
Creating a skill that is also a commandExtending: skills, MCP, subagents, hooks, plugins
A custom command and a skill are now the same mechanism: a .claude/commands/name.md file and a .claude/skills/name/SKILL.md folder both produce the /name command with the same behaviour, and for a personal or project skill, it is the folder's name, not the frontmatter's name field, that becomes the command's name.
Discovering, curating and stacking skillsExtending: skills, MCP, subagents, hooks, plugins
Search the two public libraries maintained by Anthropic, claude-plugins-official and claude-community, before writing a skill. Several skills can load together on the same task, but each adds text to the context of every session: remove any whose description no longer matches a recurring need.
MCP: the connection protocolExtending: skills, MCP, subagents, hooks, plugins
MCP is an open standard that describes how Claude Code connects to tools and data living outside it. An MCP server exposes three distinct primitives: tools Claude calls with arguments, resources it reads as content, and prompts that only the user triggers. These primitives do not substitute for one another.
Connecting an MCP server, and what changedExtending: skills, MCP, subagents, hooks, plugins
A remote MCP server connects in one command, claude mcp add, and Claude Code itself detects whether authentication is required. claude mcp list shows the real status of each declared server. Independently of Claude Code, the MCP specification changed at its core: a stateless core replaces the stateful one.
Building your own MCP serverExtending: skills, MCP, subagents, hooks, plugins
A homemade MCP server is an ordinary program that Claude Code itself launches as a child process over the stdio transport. The JSON schema declares what the tool expects, but validation remains the server's responsibility, and the description field decides whether Claude chooses that tool.
Subagents: delegating in an isolated contextExtending: skills, MCP, subagents, hooks, plugins
A subagent runs a task in its own context window, separate from the main conversation. When it finishes, only its conclusion comes back into your thread: the files read, the logs scanned and the dead ends explored stay in its own context. A good delegation gives a complete objective and a named write scope.
Hooks: automating the lifecycleExtending: skills, MCP, subagents, hooks, plugins
A hook is an action the harness runs itself when a precise lifecycle event occurs. An instruction written in memory remains a preference the model may forget; a hook declared once runs on every occurrence, independently of what the model recalls at that moment.
Hook events, from trigger to messageExtending: skills, MCP, subagents, hooks, plugins
PreToolUse runs before the tool and can prevent the call; PostToolUse runs afterwards and can only react, including by replacing the tool's result. A hook communicates its decision through a JSON object with precise fields and through its exit code, never through a sentence written to standard output.
Plugins: bundling skills, hooks, MCP and agentsExtending: skills, MCP, subagents, hooks, plugins
A plugin bundles skills, hooks, MCP servers, commands and sub-agents into a single versioned directory, installable and shareable in one go. Its manifest, plugin.json, is the only file in .claude-plugin/; the most frequent mistake is to put skills/, commands/, agents/ or hooks/ there instead of at the plugin root.
settings.json in depthExtending: skills, MCP, subagents, hooks, plugins
On a simple key present at several levels, the highest-ranking level wins entirely, while most lists, including permissions.allow and permissions.deny, merge across levels. The env block follows the same levels as the rest of the file, and a shell environment variable is not a level in this stack.
Skill routing fails silentlyExtending: skills, MCP, subagents, hooks, plugins
Claude decides whether to invoke a skill by comparing the request's vocabulary against that skill's description field alone, and a mismatch of language or jargon between the two causes automatic invocation to fail with no visible signal in the response.
Debugging and fixing a bugEveryday moves
A precise reproduction command and a complete stack trace steer the diagnosis towards the real cause of a bug, and the fix is only declared closed once a regression test reproducing the faulty case has been run and its output read.
Building and refactoring with tests firstEveryday moves
Ask for the tests before the implementation, then run the test runner to confirm they genuinely fail: red proves the test can fail, green proves the implementation satisfies it. Claude reproduces the style of the tests already in the repository, and the refactor then moves one concern at a time.
Reviewing code and driving git in natural languageEveryday moves
/code-review launches a local review with effort levels from low to max, and ultra is not one of them: it is a distinct facility, a multi-agent review in the cloud, billed separately. Git is then driven in plain language, with the same permission safety net as commands typed by hand.
Getting to grips with, documenting and migrating a codebaseEveryday moves
On an unfamiliar repository, start by asking for an overview before any change: it shapes the questions that follow. The /init command actually reads the repository's content to produce a first CLAUDE.md, a first draft to reread and trim, and migration or documentation work ends with a review of the final diff.
Automating a repetitive task and writing a throwaway scriptEveryday moves
Automating a repeated action starts with separating what stays fixed from what varies each time, is described by its input, its output and the environment it must run in, and is checked with a dry run before any step that deletes, moves or overwrites anything.
Quick terminal movesEveryday moves
A handful of short moves cover most of a day to day session: resuming a specific session, going back to an earlier checkpoint, running a shell command without leaving the conversation, and asking for deeper reasoning for a single turn without changing the setting for the whole session.
Headless mode, output styles and background tasksEveryday moves
Headless mode runs Claude Code without an interactive interface using -p, --output-format determines whether the output stays plain text or becomes a JSON object a script can use, with the total cost included, and run_in_background lets a long command keep running without blocking the conversation.
Running in parallel: worktrees, model and fast modeEveryday moves
A git worktree opens a second checkout of the repository on its own branch, so Claude Code sessions can work in parallel without overwriting each other. The claude --worktree command creates it automatically. In each worktree, the model is chosen on difficulty, and fast mode on cost.
Writing pitfalls: files, parallel edits and lost deliverablesEveryday moves
A success report written by a sub-agent proves nothing about the real state of files, since it starts in an isolated context with no access to what the main agent has already read or written, and the only reliable proof remains a diff checked afterwards, not the text of the report.
Loops, polluted context and restartingWhen things go wrong
The sign of a loop is the same failure message repeating, a saturated context is handled by a targeted compaction or a full clear, and starting over with a hand written summary of the decisions already made beats insisting inside a degraded conversation.
Undoing and recovering a changeWhen things go wrong
To undo Claude Code's last change in the current session, open the checkpoint menu with /rewind rather than going through Git first. Git remains the tool for what checkpoints ignore: changes made by a bash command, a background sub-agent's edits, and linked files.
API errors and rate limitsWhen things go wrong
An API error carries a status code that tells very different causes apart: a malformed request must be corrected before any retry, whereas a temporary rate limit resolves by respecting Retry-After. A spending cap reached carries no such header, and waiting achieves nothing: the cap itself must be raised.
A stuck commandWhen things go wrong
For a frozen shell command, press Ctrl+C, which attempts to interrupt the operation; otherwise relaunch with claude --resume. Do not add a timeout prefix by hand, because the Bash tool already carries a delay parameter that Claude chooses itself, and most commands that reach their delay switch to a background task instead of being stopped.
Several sessions die together, suspect the machineWhen things go wrong
When several sessions die at the same instant with no trace whatsoever in their own logs, the likely cause is the operating system killing processes under memory pressure, and the system log settles the question faster than a hunt through application errors.
The request may rest on a false premiseWhen things go wrong
A request for a fix mixes an observed symptom with an assumed cause: the symptom can be accurate while the cause is false. Carrying it out to the letter then fixes nothing. Measure the actual state, state the gap at the start of the reply, then fix the real cause.
Read the function called next, prove the culpritWhen things go wrong
A fix whose unit test goes green can be undone, within the same execution turn, by the function called right after it, and the already fixed function only becomes a proven culprit once a test has isolated its effect from that of the functions that follow.
The four levers of a long sessionContext and cost
A long session does not endlessly swell the text sent to the model, thanks to distinct levers: the cache, which reuses an identical start of conversation, clearing out useless tool outputs, compaction, which replaces the history with a summary, and delegation to sub-agents, which return only their conclusion.
Compacting, clearing, reading just what is neededContext and cost
The /compact command replaces the message history with a summary and carries on the same conversation, the /clear command wipes that history and starts from scratch, and in both cases the project files on disk do not move: the move that saves the most remains getting Claude to read only the relevant slice of a file.
Prompt cache and the Batch API, two discounts worth knowingContext and cost
The prompt cache and the Batch API are two different discounts on the same token cost. The cache rewards a start of conversation that does not change, the Batch API a volume of requests that can wait. The cache's lifetime depends on your offering: a paid subscription or an API key.
The auto-compact threshold does not do what you thinkContext and cost
The auto-compact threshold triggers a summary of the conversation when the context reaches it, it is not a wall that closes the window: a value set above the real window of the active model is capped at that window, a documented behaviour whose lack of an on-screen warning still needs to be checked for yourself.
A context window does not follow the modelContext and cost
The context window is a property of the model: recent models have the large window as their base, two older models ask for it through the [1m] suffix, and every model change is checked on screen with /model then /context.
Where the bill really comes from, and why a token count liesContext and cost
A session's cost comes not from the volume of work but from the number of times the accumulated history is sent back: every tool call rereads it, at the cache's reduced rate but never for free. A count that confuses a cached reread with a first read gives a false impression of the bill.
Quota, throughput, and routing to the cheapest modelContext and cost
Two distinct caps govern a session, the money cost and the throughput in tokens per minute, and both are handled by the same reflex: route repetitive tasks to Haiku or Sonnet, keep Opus for difficult reasoning, and wait according to a growing delay after a 429 error rather than retrying at once.
A sub-agent costs before it has done any workContext and cost
A subagent costs before it has done any work, because its conversation already contains items you did not write, loaded again at every launch. With no tools field it inherits every tool, and with no model named it runs on the same model as you. List its tools and name its model by role.
File-based memory: basic structure and disciplinesThe second brain
Claude Code's memory lives in a folder of markdown files, one fact per file classified by a type field with four values, and a note that carries a single idea linked to at least one other stays findable within seconds rather than after a full reread.
Obsidian: wikilinks, content maps and memory typesThe second brain
A wikilink is a native Obsidian feature that connects one note to another without depending on the folder each sits in. The content map is only a practice, a note that gathers links. Many people reuse Claude Code's memory type vocabulary in their own Obsidian vault, but they are two separate tools.
Querying a graph rather than rereading everythingThe second brain
A knowledge graph built once answers a question by walking explicit links, which costs noticeably fewer tokens than a full reread of the source files, a gap illustrated by a public example that carries its own caveat, and the same principle applies to an old session transcript, queried by levels before being reopened in full.
Dream and continuous learning: nightly consolidationThe second brain
A nightly memory consolidation is a personal automation built on top of a scheduled task, not a native Claude feature: it digests notes in four phases, orientation, collection, consolidation through merging and archiving, verification, and only a task that runs on the machine or in an open session can read a folder of notes stored locally.
A perishable figure in an always loaded fileThe second brain
A figure that sleeps in an always loaded file reads like today's figure, even though it may have become false. If nobody would receive an alert the day it changes, it belongs in a dated register, opened only when the question arises, and the loaded file cites the principle or points to the register.
A shared vault has no concurrent editingThe second brain
A local file notes application locks nothing on a shared network drive: a public report documents a settings folder that gets overwritten between users on this kind of mount, and the same mechanism makes plausible, without the source itself documenting it, the silent loss of a note edit.
The assistant's journal mostly talks about the assistantThe second brain
A review of a large memory corpus kept by an agent shows that most entries document the agent's own mistakes, written by it, about itself, with almost no explicit instruction from the person it is supposedly profiling: it is like judging a pilot by the aircraft's maintenance log.
Fan-out, pipeline, barrier: choosing the architecture, or giving it upSeveral agents and adversarial checking
Fan-out converges independent agents behind a barrier that waits for all of them, while a pipeline moves each item along without waiting for the others. The third option is to launch no agent at all, because a multi-agent architecture is an expensive option: start with the simplest approach that works.
Isolating and running in the background: worktrees and the dry loopSeveral agents and adversarial checking
To stop one agent overwriting another's work in the same repository, give each its own worktree with isolation: worktree. An agent started in an interactive session now runs in the background by default. To make a search know when to stop, compare each cycle against the set already known and stop once consecutive runs flag nothing new.
Making a large scale fan-out hold togetherSeveral agents and adversarial checking
A single agent writing an over-long deliverable is interrupted by an output size limit: the fix is one agent per axis, each writing its own file. Then verify the disk, never the report: write the exact list of expected files before launching, and compare it against what genuinely exists.
Deterministic workflows: schemas, checkpoints, resumptionSeveral agents and adversarial checking
A workflow is a script that chains agent calls deterministically: the same steps and the same output schema on every run. A JSON schema imposes named fields from one step to the next, and each completed step writes a checkpoint, so an interrupted workflow resumes without redoing everything.
Adversarial verification, judge panels and completeness criticsSeveral agents and adversarial checking
A verifier receives the artefact to judge, clear success criteria and the tools to check it, and an empty report is credible only if it counts what was checked. A panel compares solutions, a completeness critic compares the brief to what was delivered: roles not to be confused.
Multiplying agents can multiply the errorSeveral agents and adversarial checking
A study (an arXiv preprint) finds that independent agents, with no coordinator validating their outputs, amplify errors far more than a single agent. A coordinator that reviews each output reduces this amplification sharply, and on a task with strictly ordered steps the four multi-agent architectures tested fall behind a single agent.
An unverified premise in a prompt comes back as a conclusionSeveral agents and adversarial checking
A false premise slipped into a prompt's framing is never tested: the agent treats it as a fact and reflects it in its output, and the adversarial verifier, who only reviews that output, never sees it. In a fan-out it is repeated in every output, which gives a false impression of corroboration.
Three failure states, and accepting a risk properlySeveral agents and adversarial checking
A task queue distinguishes success, a recoverable failure that will be retried, and a definitive failure; lumping the last two into one failure category breaks the value of any alert. Accepting a risk means letting it happen and checking afterwards against a snapshot taken before execution, not ignoring it.
Remove the tool before writing the prohibitionSeveral agents and adversarial checking
An instruction that prohibits steers what an agent attempts without preventing anything: the protection that holds first removes the tools its mission does not need, then the closed list of expected effects and the prohibition by class come second and third, as instructions.
Succeeded, failed, interrupted, no traceSeveral agents and adversarial checking
When a cutoff stops a queue of tasks, a log kept outside the process, written before and after each task, separates four states: succeeded, failed, interrupted midway, and no trace of an attempt; confusing them leads you to rerun what may already have acted, or to declare failed what nobody has examined.
Capping a judge loop before launching itSeveral agents and adversarial checking
Set the cap before the first pass, in the batch's criteria: a maximum number of judge passes and of agents. The stopping criterion belongs to the judge, whom you do not control, and as long as it finds something the loop continues and its cost climbs. When the cap is reached, fix the sourced major findings and close.
Secrets: never let them pass through, never display them in the clearSecurity and data
A secret pasted into a conversation, even briefly, stays present afterwards in the logs and in any automatic review of the history, and a configuration command run for one precise purpose can display a neighbouring secret in the clear if its filter is too broad.
A committed secret is burned: rotate it now, never by the dateSecurity and data
A secret tracked by a repository is treated as compromised from the moment it is written, not when someone proves it has been read, and the fix that reaches every copy is to rotate the identifier, with history rewriting coming second and not always necessary.
Pseudonymous and anonymous are two different thingsSecurity and data
A reference number used in place of a name remains personal data as long as a correspondence table exists somewhere, which can make the recipient a processor depending on its actual role rather than a simple case of anonymisation, and a pseudonymous identity on a repository needs its own local configuration.
Auditing a skill before installing itSecurity and data
Audit a third-party skill before installing it: quarantine it, read all of its content, run a security scanner, and rotate any secret a removed skill could have touched. The most frequent risk is the hidden instruction, almost always combined with malicious code.
What an agent can leak without being asked toSecurity and data
An instruction hidden in content that Claude reads during the task, a web page, a file or a repository comment, can make it propose an outbound action you did not ask for: this is indirect prompt injection, which the documented protections reduce without eliminating.
Responsible automation: reversible first, failure reported, fix requestedSecurity and data
An automation in Auto, Accept Edits or Bypass Permissions mode runs most deletions the moment the command is reached, without confirmation: build the human checkpoint before the destructive command. A silent failure never announces itself, and a blocked fix is requested, not merely noted.
What leaves the machine, what gets archived, what never gets sharedSecurity and data
Every request sends the prompt and the response over the network and leaves a local copy readable in plain text on disk: a secret pasted once exists in two places. Archive rather than delete, because a move stays reversible. Filter an internal document before sending it: an inventory of sensitive data, then a re-read as a hostile reader.
Reading is enough to expose a secretSecurity and data
A text search over a whole folder returns every line containing the pattern, even from a hidden .env file, without any read of that file having been requested. A Read(./.env) deny rule does not cover a command that reads files without naming them, like grep -r, nor a subprocess that opens its own files.
A text-pattern guard is not a security boundarySecurity and data
A guard that refuses a word in the text of a command judges a spelling, not an effect: any spelling that avoids that word gets through, and even a list of allowed commands matched by exact equality lets through the code that an allowed command reads from a file the agent can edit.
A general agreement does not authorise a specific sendSecurity and data
An agreement given on a working method validates the way of proceeding, not a send whose content has not yet been shown: the approval to send names the text and the recipients, or the category of sends that a standing authorisation itself designates.
The request, a single point of entryThe Claude API for builders
The Claude API has a single point of entry, the POST request of the Messages API: every exchange goes through it, with a messages array and a chosen model. The max_tokens field is required, with no default value, and the response always follows the same shape, with a stop_reason saying why generation stopped.
Roles that hold, not a prefill that breaksThe Claude API for builders
Completing the start of Claude's response yourself, assistant turn prefilling, no longer works on current models: the server returns an error, except for one special case of refusal handling. A stable system instruction produces the same result without touching the messages array, and the output_config.format field constrains the shape of the output.
Tools: Claude proposes, the code decidesThe Claude API for builders
Claude never executes a tool itself: it returns a usage request, the developer's code actually executes it, then returns the result so the conversation can continue. This cycle rests on a single contract, the schema declared by input_schema. A tool is declared with name, description and input_schema.
Receiving the response as it streamsThe Claude API for builders
Streaming mode keeps the HTTP connection open and delivers the text in fragments as the model produces it, without waiting for generation to finish. The token count lives in the usage field of the last message_delta event, never in message_stop: code that looks for it there will not find it.
Two cost levers: cached memory and batch processingThe Claude API for builders
A request prefix marked as reusable costs a reduced fraction of the normal price when read back from the cache, and a set of non-urgent requests processed in a batch costs less than immediate processing, two discounts that stack with each other and with the other pricing modifiers.
Counting before sending: the context windowThe Claude API for builders
A dedicated counting endpoint returns the number of tokens in a request before it is sent, and the context window to compare against this figure is no longer one shared value across a whole model range, it now varies sharply from one family to another.
Choosing a model, switching models, and handling a refusalThe Claude API for builders
The choice of a model is a trade-off between quality, speed and cost that gets revisited with every new generation, and a refusal returned by a safety classifier is handled as a normal case of the protocol, not as a failure.
Moving to Opus 5.5 without breaking your codeThe Claude API for builders
Moving from Claude Opus 5 to Claude Opus 5.5 is not just a matter of changing the identifier: four old settings now return a 400 error, and the notes written between two tool calls arrive empty until the code sets thinking.display.
Content pipeline, from brief to shareable deliverableReal cases end to end
Content that must be translated, cited by an assistant and proofread offline is produced through a sequence of distinct roles, each with a single task: brief, drafting, voice alignment, search optimisation, batch translation, packaging. Each role starts once the previous one is finished and approved, never in parallel on the same text.
Building a data asset, synthetic dataset or knowledge baseReal cases end to end
A synthetic dataset and a knowledge base share the same architecture: batch ingestion or generation, deduplication, linking through a shared schema, then recall via a lightweight index. The schema is fixed before the first record, and deduplication happens before validation, never after.
Fan-out research, with adversarial verificationReal cases end to end
Launching searches in parallel speeds up collection, not judgement: speed changes nothing about reliability. Every claim kept must be actively contested through a distinct source before being cited with its source, and a claim that does not withstand it drops out of the draft instead of staying in a softened form.
Verify before believing, four real trapsReal cases end to end
A report written by a third party's agent, a paid skill sold as a bundle of features, a data connector announced as synced, and a competitor's page displaying a missing feature share the same flaw: each replaces a direct measurement with a claim that would need checking before being cited.
A mobile application from end to endReal cases end to end
One work session is enough to chain a scaffold (the starting structure generated for an app), navigation between screens, a network call and the correction of flagged types, provided you keep the preview, which updates on your phone, open from the first screen. An error seen right after it is introduced is corrected within seconds.
Automating your own practice, stack and skillReal cases end to end
A move that keeps repeating identically becomes a named command, invoked with a word rather than rebuilt every time. Distinct layers let it work on its own: the scriptable call does the work, the lifecycle trigger decides when to launch it, distilled memory keeps what needs to be remembered.
Making your site readable by AIs, citation and agentic navigationReal cases end to end
Citation by an assistant and agentic navigation are two distinct capabilities, checked by two distinct controls. Citation depends first on what other pages say about the site, and markup does not create it; navigation plays out on the page, where a button with no text or accessible label stays invisible to an agent.
Warm-up, assembling a prompt and ticking your checklistWorkshop, capstone and exam
The warm-up writes no line of code: it checks that the reflexes you have built come back on their own, with no notes. Rebuild a complete prompt from memory, then tick the practitioner's checklist point by point before the next project; each missing block points to a reflex not yet installed.
Placing yourself, from beginner to expert, before choosing your projectWorkshop, capstone and exam
Four levels of autonomy, a Project fitted with instructions, a Claude Code session framed by a configuration file, a homemade skill, a linked and consolidated memory folder, show which of the three end of course projects matches your own level.
The capstone, three real projects to choose fromWorkshop, capstone and exam
The capstone is passed by delivering one of three projects of your choice all the way through: a feature, a second brain or a content pipeline. The plan is approved before execution, the scope fits in a single session, and the final check happens in the real environment.
Advanced capstone, the multi-agent adversarial reviewWorkshop, capstone and exam
A single reviewer often falls into the same blind spot as whoever wrote the code. Distributing the review across several subagents, each with a narrow role, corrects this bias, provided the roles stay distinct, no incomplete output passes on to the next step, and the final synthesis surfaces disagreements instead of smoothing them.
The graduation checklist, the final examWorkshop, capstone and exam
Rereading your checklist and telling yourself yes, I know how to do that, proves nothing: a reread confirms what you already believe you know. The version that reveals a gap asks you to cite the precise action that proves each point; if all you have is the memory of reading it, do not tick the box.