Why this matters now

Since 2023, using an AI assistant well meant writing a better prompt. In 2026, that is no longer where the difference lies.

The paradigm changed

The unit of value has moved from the prompt to the system: a configured environment that already knows who you are, what you are working on, and which sources it may use. Someone who only asks questions is using a fraction of what is available; someone who has set up context, tools and repeatable processes is working at a different rate.

Four ideas before you start

How far it goes: four steps

When someone says they "use AI", they are almost always on the first step. There are four, and this whole handbook is the climb.

Two distances have closed in twenty years. The internet and the chatbots closed the one between wanting to know something and knowing it. Claude Code closes the one between knowing what to do and doing it. What no tool closes is what comes before both: knowing what you want. Judgement, experience and the patience to iterate — your part has not disappeared, it has concentrated.

What Claude is, beyond a chat window

Think of the employee you would want: remembers you, has routines, knows how to do things, and has access to what they need. Claude has all four pieces; the rest is telling it what you want.

• Chat and Cowork — chosen from the main text box. Chat is for thinking; Cowork is for delegating complete tasks.
• Projects group conversations, instructions, files and memory around one context.
• Skills teach Claude processes and criteria it can reuse whenever they apply.
• Plugins bundle skills, connectors, tools and specialised subagents.
• Scheduled tasks repeat work automatically, without you present.
• Connectors let Claude read and act inside external applications, within the permissions you grant.
• Subagents split a large job across several Claudes at once, each with its own brief.

This handbook takes those pieces in order, from first login to full automation.

How to use this handbook

Parts One to Three are the reference: what each piece is, when it earns its place, and the habits that keep it safe and affordable. Part Four is the practice: a two-hour guided session that assumes the reference exists and does not re-explain it. In a classroom setting, Part Four is the session plan and the rest is the pre-reading; on your own, you can run Part Four first and come back to the reference when a concept needs depth. Part Five is for when the system already works and you want to build something with it that other people can open at a URL.

Account and privacy

Create your account at claude.ai, either with a Google account or with a sign-in link sent to your email. When asked which plan you want, you can start on the free one (for Claude Code, for example, you will need a paid one). You will know when you need more, and §1.5 explains when that is.

Settle privacy before your first prompt

When you create the account, Claude asks whether your chats and coding sessions may be used to improve its models. If you said yes, or do not remember, check it before your first prompt — and if you intend to work with client information, contracts or internal strategy, turn it off.

From that point your conversations sit outside training. Institutional and enterprise accounts are governed by their own agreement — if you are working under one, check what already applies before changing anything.

Bring your context across

If you have spent months with another assistant, you do not have to start from nothing. Claude can import the context that ChatGPT, Gemini or Copilot already hold about you.

How it works. Claude generates a prompt. You run that prompt in the other assistant, copy the answer, and paste it back. The transfer takes a few minutes, and the import is experimental: check what came across.

Step by step

1. In Claude: Settings → Memory → Start import (on accounts still on the older layout: Settings → Capabilities → Memory).
2. Copy the prompt Claude gives you.
3. Open a new conversation in the other assistant — ChatGPT, Gemini or Copilot — and paste it.
4. Give it a moment to produce the full summary, then copy the whole answer.
5. Return to Claude and paste it where indicated.

If you also want the full conversation history

• ChatGPT — Settings → Data controls → Export data. A ZIP arrives by email.
• Gemini — go to takeout.google.com, select My Gemini Activity and download.

Two files worth writing once

An assistant that has never met you spends the first minutes of every session being briefed. Two short files retire that ritual for good.

Build them from the data you exported in §1.2. Paste that material into Claude and ask it, in your own words, to turn it into each of the two files. Then download them and upload them to your Claude folder and to every project that matters, so they are read in every conversation in that context.

ABOUT-ME.md you build from the §1.2 export, or from the CLAUDE.md form in §4.3, which asks the same questions. ANTI-AI-STYLE.md — together with its positive twin, WRITING-STYLE.md — is written for you by the voice form in §4.3, next to the CLAUDE.md generator, from your answers and your samples.

Web, desktop and mobile

Six ways in, each for a different moment. The first three are Claude itself; the last three put it where you already work.

Plans and what each includes

Move up a plan when the limits start interrupting your work, not before.

One way to decide: what is an hour of yours worth? If the next plan gives you two or three back a month, it has paid for itself. And before moving up, look at when you hit the ceiling: a limit reached mid-afternoon is often a matter of pace, not of plan — §3.6 fixes more of that than it seems.

Tokens and models

Models do not read words; they read tokens, which are slightly smaller. Two or three rules of thumb are enough to reason about cost:

• 1 token ≈ 3.5 English characters — Anthropic's own figure; Spanish spends a few more tokens per word
• Rule of thumb: 1,000 tokens ≈ 700–750 words
• A full A4 page of text ≈ 650–800 tokens

Every message you send and every answer you receive consumes tokens — input and output both. That is what your plan measures.

Two more dials: thinking and effort

Besides which model, there are two settings. Thinking is whether Claude reasons before answering and shows you a summary of that reasoning — useful in itself, because you can see where an argument went wrong instead of just distrusting the conclusion. On Fable 5.1, Opus 5.5, Sonnet 5.5 and Haiku 5.5 it is always on: you set how deep it goes with effort rather than switching it off. Effort is how hard it works on each answer, in five levels from low to max; it sits next to the send button in Claude, and in Cowork and Claude Code (§3.4).

More effort costs more tokens and more time, so treat it like the model choice: low or medium for lookups and routine drafting, the model's own default for most work (marked Default in the effort menu; Opus 5.5 and Haiku 5.5 start at medium) — and the top levels for multi-step reasoning, numbers you need to trust, and decisions with real trade-offs. To save tokens you do not switch thinking off — you lower the effort.

Chat and Cowork

The main text box is where you choose how Claude works. Chat is for conversation: thinking, analysing, researching, drafting. Cowork is different — Claude leaves the conversation and acts directly on your computer.

With Cowork active, Claude can open applications, read files from disk, edit documents, move through folders and run chained tasks. You give an instruction in plain language and it carries it out on your system.

Turning it on

Cowork needs a paid plan. It lives in the desktop app, on the web and on mobile (in beta on Team and Enterprise); to reach the files, applications and browser on your computer it needs the desktop app open. Select it in the text box. The first time, it asks for permission to reach your system — you decide which folders and applications it may see.

You decide how far it goes.

Projects: your work organised by context

Conversations are islands: what you established in one is unknown to the next. A project turns them into a mainland.

It is a container where everything about one subject lives together — the conversations, a standing set of instructions, the documents that matter, and a memory of its own. You assemble it once and it is there every time you return.

What a project holds

Creating one

When to use one

One project per distinct context. Mixing a marketing client with a legal matter and a personal blog costs Claude the thread, and costs you the thread too. Separate them, organise them, and Claude works in each as though it had been with you for months.

Your voice: writing like you, not like a model

Projects govern what Claude knows. Four things govern how it writes, and they stack.

Instructions for Claude. An account-wide text that every conversation reads: register, sentence length, how much structure, what to avoid, the terms you use. Write it once from samples of your own writing, so that what comes back reads like you rather than like a model.

Project instructions (§2.2) narrow that for one context — a client, a course, a blog. A writing skill (§2.7) goes further: a protocol for one kind of piece, loaded only when that piece comes up — the LinkedIn post, the client email, the report.

The ANTI-AI-STYLE file from §1.3 is the fourth leg, from the other direction: the instructions describe what to do, the file describes what to avoid. Used together they are the difference between text you can send and text you have to rewrite. The form in §4.3 writes that file for you, together with its positive twin, WRITING-STYLE.md.

Memory: managing what Claude knows about you

Memory is less mysterious than it sounds: Claude keeps fragments from your conversations and brings them back when they fit what you are doing.

Two kinds of memory

• Conversation memory. Claude extracts what matters from your conversations — what you do, how you work, preferences you have mentioned — and accumulates it on its own.
• Project memory. Inside each project, Claude builds a separate memory of the key ideas in that context. It does not mix with the rest.

Turning it on and managing it

On accounts still on the older layout it sits under Settings → Capabilities. Make sure both switches are on — Generate memory from chats and Search and reference chats. From the same place you can see everything Claude has stored about you, edit it or delete it. It is worth reviewing every so often — memory sometimes keeps things that are out of date, or that you would simply rather it did not hold.

Artifacts: from conversation to deliverable

Ask for something that is not prose — a document, a model, a deck, a script — and the answer does not arrive as a wall of text in the chat. It arrives as an artifact — a piece of work that lives beside the conversation — or, for Office formats, as a real file, ready to download and use.

What you can create

Artifacts proper are documents, code, HTML and diagrams that render on screen. File creation — on for every account, and switched at Settings → Capabilities — adds the Office formats:

• Word (.docx) — reports, proposals, contracts, templates
• Excel (.xlsx) — calculators, tables, models with formulas
• PowerPoint (.pptx) — structured, designed presentations
• HTML — landing pages, emails, web components
• Code — scripts in Python, JavaScript or any other language
• Images and diagrams — flows, mind maps, schematics

The conversation and the artifact sit side by side. Ask for changes in the conversation and the artifact updates as you go. When it is right, you download it in one click.

Saved artifacts live in the sidebar, in their own section.

When the deliverable is visual: Claude Design

Artifacts cover documents, spreadsheets and code. When what you need is a screen — an app interface, a landing page, a poster, a one-pager — that is Claude Design's territory. Describe the piece in plain language and it proposes a designed version: layout, hierarchy, navigation, reusable components that keep every screen consistent. You refine it the same way you asked for it — by saying what should change — or by editing elements directly on the canvas, and the result can move on to Canva or to a presentation.

What it is for: putting something tangible in front of people before anyone writes code or opens a design tool. A founder validating an idea, a team agreeing on a flow, a first version of a campaign piece. What it is not: a replacement for a designer on complex work — and the vaguer your brief, the more generic the screens, so the thinking you would put into a §2.2 project brief belongs here too.

Connectors: Claude inside your applications

Out of the box, Claude is sealed off: it sees the conversation and nothing else. Connectors open doors — one per application — so it can look inside your tools and act there.

MCP stands for Model Context Protocol. You do not need to know what that means — only that it is the standard that lets Claude connect to almost any application.

What you can connect

Google Drive, Gmail, Notion, Slack, Calendar, GitHub, Canva, HubSpot, Microsoft 365, Jira (through the Atlassian connector), and a list that grows every week. If you use an application, there is a reasonable chance a connector already exists.

What it can do once connected

Not only read — act. Search files in your Drive, read email, create calendar events, update tasks in Notion, send messages in Slack. All from the conversation, without changing window.

Find the application, select it, and follow the process. In most cases it only asks you to sign in to your account.

Skills and plugins: teaching it to work the way you do

General competence is the easy part; Claude arrives with it. What no model arrives with is your way of doing things — the shape of your reports, the rhythm of your scripts, the sequence you run when a client signs. Skills and plugins are where that goes.

Skills

A skill is a set of instructions telling Claude how to carry out a specific task. Not what to do, but exactly how.

A skill for LinkedIn posts, for example, might specify a one-line hook to open, no bold anywhere, a closing question, and a direct register throughout. Every time it runs, Claude follows that protocol without being told again.

A skill can be a task or a role

There are two ways to think about a skill, and it helps to have both.

As a task. A procedure with steps: the meeting summary, the LinkedIn post, the commercial proposal. It runs when the task comes up.

As a role. A skill that behaves like someone on your team. /lawyer reviews a contract the way your lawyer would: jurisdiction, balance between the parties, what exposes you specifically. /cfo reads a financial plan. /sceptical-client reads your proposal. You call it by name — or by the name of the person who used to do that job, if it helps: /john — and it already knows what to do and what to look for.

Roles have an advantage tasks do not: they can be set against each other. Two skills looking at the same thing from opposite sides are the cheapest way to amplify (§00, step 02). /tax-adviser tells you which invoices are missing; /tax-inspector tells you which ones should not be there. Buyer and seller. Your lawyer and theirs. Each sees what the other is not looking for.

How to create a role without writing it. Ask Claude to interview you:

Let's create a skill that acts as a contracts lawyer.
Ask me the questions you need to define it well — which
jurisdiction, which kinds of contract, which side I review
from, what worries me most — one at a time. When you have
enough, write it to ~/.claude/skills/lawyer/SKILL.md.

Answer with what you know. "I don't know" is also an answer, and a better one than making something up: Claude will pick a reasonable default and tell you it did.

Plugins

A plugin is a set of skills already packaged for a use case. Instead of building everything from scratch, you install it and get several capabilities at once — project management, content, data analysis, customer support and more. Some are published by Anthropic, others by the community.

The same place on the web and in the desktop app; plugins need a paid plan. They can also be imported from a marketplace, or built with Claude.

Your context folder: memory that belongs to you

Projects (§2.2) and memory (§2.4) live in your account. If the account belongs to your company or your school and one day stops being yours, they go with it. There is an alternative that depends on nobody: a folder with text files in it — on your computer, or in a synced folder such as Google Drive or Dropbox if you want it on every device. One caution with online folders: whatever lives there is reachable by anyone who gets into that account, so treat it as you would client data — two-step sign-in on the account, no secrets in the files (passwords, API keys), and the rules of §3.5 before you connect Claude to it.

What it is. One folder, subfolders by area, and one .md file per topic. Claude Code reads it at the start of every session — it is the project folder you open in Claude Code (§3.4) — and so does Cowork, if you point it there. What is in the folder, Claude knows. What you delete, it stops knowing.

context/
  CLAUDE.md          rules for this folder — your profile lives in ~/.claude/CLAUDE.md (§4.3)
  company/
    strategy.md      what you do, for whom, what you do not do
    clients.md       who is a client, who is at proposal, who went cold
    icp.md           who you sell to and who you do not
    objections.md    why people do not buy from you
  people/
    ana-lopez.md     role, what matters to her, how she likes to be written to
    ...
  skills/            §2.7 and §4.5

How to write it without writing it. The same way as the CLAUDE.md in §4.3: ask Claude to interview you. "Let's create the context file for my company. Ask me the questions you need, one at a time, and at the end write it to company/strategy.md." Half an hour of questions produces a document most companies do not have.

How to keep it current. Two ways, both valid. You, by hand, because it is text. Or Claude: "Read my email from the last two weeks and update clients.md: who has become a client, who is at proposal stage, who has gone a month without replying. Tell me what you changed." Scheduled every Monday (§3.1), it stops being a task.

Three rules that keep it useful

1. One file per topic, and short. Claude loads them when needed; a long file reads worse and costs more.
2. Your strategy, in a file you can reread. It is worth more for what it forces you to write than for what it gives Claude. Almost nobody keeps their strategy somewhere it can be reread in five minutes.
3. You control the memory. When Claude updates a file, ask it to tell you what changed, and correct what is not true. It is your folder, not its.

Scheduled tasks: work that runs itself

Everything so far waits for you to ask. A scheduled task does not wait.

A scheduled task is an instruction you give once, and Claude runs it whenever the condition you set is met — a specific time, a frequency, an interval.

What that looks like in practice

• Every Monday at 07:30, read the week's email and update clients.md in your context folder (§2.8): who became a client, who is at proposal stage, who has gone a month without replying
• Every Monday at 08:00, review the projects folder and produce a status summary
• Every day at 07:00, gather sector news and prepare a briefing
• Every Friday, analyse the week's files and write a report
• Every day at 18:00, read what arrived in a shared Drive folder and log it in a sheet

Write the instruction in plain language, define when it runs, and save. Claude handles the rest.

Why it matters. The repetitive work you do every week — reviewing, summarising, preparing, organising — can leave your list entirely. You are not delegating it to a person. You automate it once and it stops existing as a task of yours.

Dispatch: directing your desktop from your phone

Cowork acts on your computer, and some things only happen there. Dispatch closes the loop: it lets you direct Claude from your phone while the computer stays where it is.

Something occurs to you while you are out — a task, a request, an idea you want developed. Instead of noting it down for later, you send it to Claude, and it runs on your desktop.

Setting it up

1. Install the Claude app on your phone (App Store or Google Play) and sign in with the same account as on your desktop.
2. Open Cowork — on the desktop or on the phone — and choose Dispatch in the left side panel.
3. Choose Get started and follow the steps: allow file access, and allow the computer to be woken.
4. Finish setup. With one account on both devices there is nothing to link by hand.
5. Enable notifications so you are told as tasks progress.

What it is not. Dispatch is not a way to work from your phone. The result happens on the desktop, not on the handset. It is for delegating while you are moving, not for replacing the computer. Dispatch is a limited beta on the Pro and Max plans and, as of September 2026, is not being opened to new accounts: whoever already has it keeps it for now. If Dispatch is not in Cowork's side panel, your account does not have it — Remote Control (§4.2) covers the same need for Claude Code sessions.

Claude in Chrome: the browser agent

Claude in Chrome is an extension that installs Claude directly in your browser. From there it can read what you have open and, if you allow it, act inside web pages.

Installing it

Go to the Chrome Web Store and search for Claude — check that it is the official one — or install it from the desktop app.

Sign in to the extension with your Claude account and it is ready; it needs a paid plan. It works only with Google Chrome; Safari, Firefox and Edge are not supported.

Two things it does, and they are not the same

Where it shows

On the sites you already have open. In LinkedIn, it can read the profiles that visited yours and tell you which one is worth writing to and why. In WhatsApp Web, it can go through your recent chats, find the messages you never answered and draft a reply for each. In a web form, it fills in what you tell it and stops before sending. In a comparison — three suppliers, three tabs — it reads all three and puts them side by side. The pattern is the same every time: it browses, reads, compares and comes back with a recommendation; what you do with it stays yours.

Claude Code

Claude Code works directly with code and files from your computer's terminal. It is not a chat — it is an agent that reads, modifies and runs things inside your real project, and, if needed and with your permission, in your other folders and on your computer.

It requires a paid plan (Pro, Max, Team or Enterprise). The free account does not include access.

Where it already is, and what to install

The desktop app (its Code tab) and the VS Code extension include Claude Code: nothing to install. The terminal installer below adds the claude command to your terminal — the alternative door in Part Four, which uses the desktop app's Code tab by default; install it if you prefer the terminal or want it as a backup.

macOS

curl -fsSL https://claude.ai/install.sh | bash

Nothing else needs installing beforehand, and it updates itself.

Windows, from PowerShell

irm https://claude.ai/install.ps1 | iex

PowerShell ships with Windows 10 and 11 — press the Windows key, type PowerShell and press Enter. Installing Git for Windows (git-scm.com) first is recommended, not required: with it, Claude Code gets its full command toolkit; without it, it falls back to PowerShell and still works.

Check that it worked

claude --version

The first time you run claude, a browser opens so you can sign in with your Claude account. There are no further steps; /login switches accounts later if you need to.

Two ways to use it

• From the terminal. Go to your project folder, type claude, and work in plain language. In your first session it asks before every change; after that the starting mode depends on your plan (§4.2).
• From the desktop app. Once the app is installed, Claude Code is its Code tab: pick a folder and you are in. You can follow changes as they happen without touching the terminal.

What the desktop app adds

VS Code. Install the official Anthropic extension to see visual diffs and approve or reject each change with a button. VS Code itself: code.visualstudio.com/download. The extension: marketplace.visualstudio.com — Claude Code, or inside VS Code press Ctrl+Shift+X (Cmd+Shift+X on Mac), search for "Claude Code" and click Install. Setup guide: code.claude.com/docs/en/vs-code.

Who it is for. It was built for people who work with code — but it has stopped being only that. If you have never touched a terminal, do not start here: Part Four takes you from zero to a working setup in two hours, no programming required.

Working safely

Seven rules that cover most of what goes wrong.

1. Read what Claude proposes before you approve it. It asks before everything only in Manual mode; accept edits still asks before commands; Plan proposes first; and, since Claude Code 2.1.283, every plan starts a session in auto, where an automatic reviewer checks routine actions instead of you (Shift + Tab in the terminal, the mode selector in the app). Never approve blind — and never assume it asked.

2. Start in Plan mode. Claude proposes before it touches anything; give it more autonomy once you know how it behaves.

3. Use Git whenever you use Claude Code. Commit before asking for significant changes — without version control there is no safety net.

4. Turn connectors off when you are not using them. Every active connector is an open door; close it when you do not need it.

5. Check before connecting institutional tools. Do not connect corporate systems without speaking to whoever manages security.

6. Review what it has done. Agentic AI makes mistakes, so read the result before treating it as finished.

7. Install plugins only from sources you trust. A malicious plugin can reach your data and your connected tools.

Spending tokens well

Seven habits that make a plan go considerably further.

1. Let one model carry about 90% of the work. Opus is the sensible default for professional use; keep Fable for what is genuinely hard or very long. Drop to a smaller model when a task is simple and you want it fast. And lower the effort level (§3.4) to low or medium for routine work; the higher levels are for the rest.

2. Markdown files are the most efficient format. A .md file consumes far fewer tokens than a formatted PDF or Word document.

3. Add files to the project, not to the conversation. Project files are indexed once; attaching them in every chat spends tokens repeatedly.

4. Keep instruction files short. Every line counts as tokens, and if a file runs too long, parts of it get ignored.

5. Compact a conversation when it grows long. Summarising the history frees context before you ask for something new and complex.

6. Watch the usage panel. Know how much you have spent and what share of the plan is gone before you hit the limit.

7. Let Claude write down what it already knows. If a task repeats over a folder that keeps growing — invoices, applications, contracts — ask it to note in a pending.md what it has reviewed and what is left. Next time it reads that file, not the whole folder.

Several Claudes at once: subagents

A Claude Code session can launch subagents: child sessions with their own brief and their own context window, which work separately — several at a time if needed — and return only the result. You talk to one; it delegates.

When it pays. When the parts of a job do not depend on each other: three analyses of three markets, a review from three angles, research across several sources. When each step needs the one before, a single Claude does it better.

Skill or subagent. A role as a skill (§2.7) works inside your conversation and sees everything you have seen. The same role as a subagent works apart, starts clean, and does not clutter your conversation with what it reads along the way. To review or research in parallel, use a subagent. They are defined like a skill — a Markdown file with a name and a description — in .claude/agents/ for one project or ~/.claude/agents/ for all of them, and the fastest way is to ask Claude to create it.

The pattern, in three steps

1. A coordinator. Ask it to decide who is needed — and to say who it leaves out and why. That list of exclusions is the most useful part: if it leaves out the wrong role, correct it before anything starts.
2. In parallel, each to its own file. Have every subagent write its conclusions to its own .md. Files, not chat: they stay, they can be reread, and they do not compete for the context window.
3. Synthesis. The coordinator reads the files and writes a single one: what agrees, what contradicts, and what it recommends.

Act as coordinator. I need an analysis of how to sell our
training programmes in two new markets: [X] and [Y]. Choose
three different profiles to approach it and explain why those
and not others. Launch them in parallel as subagents; have each
write its analysis to analysis/<profile>.md. When they finish,
read all three and write analysis/synthesis.md with agreements,
contradictions and one recommendation.

The plan, and where to run it

Two hours, five blocks. Nothing here requires programming — the skill you need is knowing how to ask, and this sprint teaches you the asking. The classroom version runs three hours: it adds the theory of Parts One to Three, a break, and the safety and subagent blocks — its slides point to the sections here.

Where to run it

Claude Code runs in several places — the six below plus the web at claude.ai/code, JetBrains IDEs and Slack. All of them run the same agent; the difference is what you see while it works. (§1.4 compared Claude's apps in general — this table is specifically about Claude Code.)

Install and survival kit

Installation is covered step by step in §3.4 — macOS is one command, Windows is one command, plus Git if you want the full toolkit. The desktop app already includes Claude Code: it is the Code tab, and that is the door this sprint uses by default — open the Claude app, click Code, choose your working folder, and you are in: no terminal, nothing else to install. The terminal is the alternative if you prefer it: install the command (§3.4), confirm with claude --version, open your working folder and type claude. Both read the same CLAUDE.md, skills and connectors, so nothing in this part depends on which one you choose.

These are the commands that cover the first month. Everything else can wait. In the Code tab of the desktop app the slash commands work the same way — type / in the prompt box; claude and /exit are the terminal's way of opening and closing a session, which in the app is just opening and closing the tab.

Three files worth knowing from day one

• CLAUDE.md — the rules and context Claude loads at the start of every session. §4.3 builds yours.
• ~/.claude/skills/ — where your skills live, one folder per skill. §4.5 creates your first.
• .claude/settings.json — per-project permissions: what Claude may run, edit or never touch.

Your profile: generate your CLAUDE.md

Section 00 made the argument: the value has moved from writing perfect instructions to organising your context once. CLAUDE.md is where that starts. It loads at the beginning of every session — your role, your rules, your tools — so you stop repeating yourself in message one.

For a code project, /init drafts one from the folder itself. For your professional profile — who you are, regardless of project — fill in the form below. The file updates as you type; nothing you enter leaves this page.

If you wrote the ABOUT-ME file in §1.3, you have already done the thinking: same idea, different home. ABOUT-ME feeds your chat projects; CLAUDE.md feeds Claude Code sessions. Reuse its content here rather than starting again — the two files should agree with each other.

Where to put it

• ~/.claude/CLAUDE.md — global: loads in every session, every folder. Your profile belongs here. The easy way to get it there: copy the text above, paste it into Claude Code and say “save this as ~/.claude/CLAUDE.md” — it creates the hidden folder for you. Then /clear and ask “who am I?”.
• project folder/CLAUDE.md — per project: rules for that context only. Both load together.

Your voice: Claude writes like you, not like Claude

By default Claude writes like Claude: correct, structured, and recognisable as AI from a kilometre away. Three ways to fix it — combine all three:

The form turns the three into one prompt to paste in Claude, plus drafts of the two files Claude will hand back: WRITING-STYLE.md, how you write, and ANTI-AI-STYLE.md, what it must avoid. Create as many voices as you want — one for LinkedIn, one for client emails, one for your newsletter. Why it matters: text that sounds like you travels further, needs less editing, and does not give away the machine.

Where to save them — and ABOUT-ME.md with them

Paste the prompt in a new chat (attach the PDF if you have one). Claude answers with what it noticed in your writing and the two finished files. Download them — or download the drafts here if you are in a hurry — and put them in three places:

• On your computer. In your context folder (§2.8), next to ABOUT-ME.md: context/WRITING-STYLE.md and context/ANTI-AI-STYLE.md. This is the copy you own — it survives a change of account, plan or tool. If you have no context folder yet, any folder you will not lose is fine for today.
• In Claude — chat and projects. Upload both files to every project that matters (open the project → add files), so each conversation in that context reads them. The two-line summary of your register also goes in Settings → Instructions for Claude (§2.3), which applies everywhere.
• In Claude Code. Keep them in the folder you open, and add one line to the CLAUDE.md you just generated above: “Before writing anything in my name, read WRITING-STYLE.md and ANTI-AI-STYLE.md.” Claude Code reads files when told to; that line is what makes it look.

Connect your first application

§2.6 explained what connectors are; this block is only about doing it. One thing matters here: a connector set up once serves both chat and Claude Code, so these thirty minutes pay off everywhere.

The five-step route

1. In Claude, open Sidebar → Customise → Connectors → +.
2. Search for the application — start with Google Drive or Gmail.
3. Select Connect and read what it asks permission for. Actually read it.
4. Authorise with the application's own sign-in.
5. Done. A connector set up on this machine also serves Claude Code — /mcp lists what a session can reach.

One caveat before you click, and it is the one from §2.6: if this is an institutional account, have that conversation with your security people first.

Your first skill

You now have two places to teach Claude things, and the boundary between them is one sentence: CLAUDE.md is who you are. Skills are what you know how to do.

A consultant keeps name, language and formatting rules in CLAUDE.md — and proposal generation, invoicing and report layout as three separate skills.

Create a personal skill called meeting-summary. Save it as
~/.claude/skills/meeting-summary/SKILL.md with exactly this content:

---
name: meeting-summary
description: Turn a meeting transcript or raw notes
  into a structured summary with action items
---

When given a transcript or meeting notes:

1. Summarise in five lines maximum, plain language.
2. List decisions taken, one per line.
3. List action items as: owner — task — deadline.
4. Flag anything left unresolved under "Open".
5. Ask nothing; if information is missing, write "not stated".

Checkpoint, and what comes after

Two hours in, you should be able to tick four boxes: Claude Code opens a session in a folder of yours — the Code tab, or claude --version in the terminal; your CLAUDE.md sits in ~/.claude/ and a new session already knows who you are; Exercise 1 found a real document through a connector; Exercise 2's skill fires on any pasted notes. Anything unticked, redo that block — the order matters less than the verification.

When connectors are not enough

Connectors cover roughly 80% of professional cases. For the rest, there is a ladder — climb only as far as you need:

1. Connectors — first stop, always. Visual setup, OAuth, no terminal.
2. MCP servers — claude mcp add for internal or custom tools; the protocol lets Claude discover what a server offers by itself.
3. Command-line tools — gh, stripe, vercel and friends. If a CLI exists, Claude Code can drive it.
4. Direct APIs — full control, for things headed to production.
5. Web scraping — last resort. Fragile, and check the site's terms before you touch it.

Most working setups settle on two or three MCP servers plus a couple of CLI tools. Combine; do not collect.

If your organisation runs on Slack

On Team and Enterprise plans, Claude Tag (in beta) joins Slack as a colleague: mention @Claude in a channel and delegate. Access is set per channel, workspace or organisation; the memory of public channels is shared across the workspace, that of private channels stays in the channel. Standing instructions are written from the Configure link under any of its replies and act as the channel's CLAUDE.md. Two habits from day one: write those instructions before the first request, and have your administrator set a spending cap and choose the default model per channel when enabling it — unbounded first weeks show up on invoices.

What's next after today: the expert tier

Five ideas from earlier in this handbook become your next five sessions. Each one is a door you have already seen — now you have the setup to walk through it.

And when even that feels small, Part Five takes over: building something other people can open at a URL, with Git as the safety net, seven reviews before you trust it, a test environment before the real one, and a database when things need to persist. The sprint you just did becomes work that runs without you — and §3.7 explains how to split it across several Claudes at once.

Keep learning: Claude Academy

Anthropic runs Claude Academy, a free training platform at academy.claude.com, with courses in English and no cost to enrol. Two are worth every student's time before or after this sprint: AI Fluency: Framework & Foundations (14 lessons, about 4 hours — how to collaborate with AI effectively, efficiently, ethically and safely) and AI Capabilities and Limitations (13 lessons, about 3.5 hours — what these models can and cannot do, and why). The Academy also carries product tracks for Claude, Cowork, Claude Code, Claude Tag (Slack) and the Claude Platform, which pick up where this handbook stops. Catalogue as listed on 15 September 2026.

Official references

The facts in this handbook — prices, model specifications, commands, installation — were verified against Anthropic's own documentation on 27 August 2026, and the whole document again — plans, models, Claude Code, app features and Claude Academy — on 15 September 2026, on 28 September 2026, on 5 October 2026 and on 12 October 2026 and on 19 October 2026. Since then the document is updated automatically every week; the latest run is dated 26 October 2026. These pages are also where to check when something here has aged:

• Claude Code documentationEN— installation, commands, permission modes (§3.4, §4.2)
• Model specificationsEN— context windows and output limits (§1.6)
• Claude Help CenterEN— current plans and pricing (§1.5)
• Claude AcademyEN— free official courses

Before you build: perimeter and security

A prototype that is going to sit at a public URL is treated from the first minute as if it already did. Five things before the first line:

1. A new, empty folder, for this project only. Nothing gets built inside the context folder (§2.8) or in Downloads.

2. Git from the first minute. git init, or ask Claude. Every step that works, a commit: it is the undo button, and in §5.4 it is also the way out.

3. A .gitignore before the first commit, with .env, keys and dependency folders in it. What is in there never goes up to GitHub. Claude writes it if you ask; you check that .env is inside.

4. Secrets out of the code. Passwords, API keys, connection strings: in a local .env file and, later, in Vercel's environment variables. Never in a file Claude is going to write as code, never pasted into the conversation. Keep the master copy in a password manager such as 1Password or Bitwarden: one vault, one strong password, every key inside it — you copy a key out only to put it into .env or into Vercel, never into a chat. If a key leaks anyway, revoke it where it was issued and create a new one: a leaked key is no longer a secret.

5. The rules, in the project's CLAUDE.md. A new session loads them without you repeating them:

# Rules for this project
- Never write keys, passwords or tokens into the code:
  use environment variables.
- Before installing a library, say which one and why.
- Do not delete or move files without asking.
- Every block that works, propose a commit with a clear message.
- If anything in PRD.md is ambiguous, ask; do not assume.
- Nothing is published to production without going through
  staging first (§5.4).

Define before you build: the PRD and the first prototype

A PRD — product requirements document — says what the product does, for whom, and what is left out. It is what a product team writes before anyone programs. Here Claude writes it, but the answers are yours.

Step 1: the role, and the questions.

Act as a senior digital product manager. I want to build
[a tool for X]. Before proposing anything, ask me the questions
you need to write a PRD: who uses it, what problem it solves,
what it must be able to do in the first version, what is left
out, what data it handles and how we will know it works. One at
a time. When you have enough, write PRD.md in the folder.

Answer with what you know. "I don't know" is a valid answer and a better one than making something up. The most valuable section of the document is the one about what is left out: it is what stops the first version from trying to be the third.

Step 2: the smallest prototype that works.

Read PRD.md and build the smallest version that works end to
end: it must open in the browser and complete the main journey,
even if the data is sample data and the look is provisional.
Add nothing that is not in the PRD. Show me the plan before you
touch anything.

"Works" means the whole journey can be done — get in, do the thing, see the result — not that one part is perfect. A small version that works end to end can be improved; a perfect piece of something that does not work yet cannot.

In plan mode, Claude shows you first what it is going to do. Read it, cut what is not needed and approve — it will ask whether to carry on approving each edit by hand or in auto mode; start by hand — and let it build. When it opens in your browser and the main journey completes, commit: "first prototype".

Seven reviews before you trust the prototype

The first version works. It is not good yet, and you will not find that out by looking at it yourself. In a product team, seven different people would review it, each looking for a different kind of fault. Here all seven are Claude, and what matters is that each one looks only at its own thing.

How to launch them. In parallel, as subagents (§3.7): six reviewers who write to files and do not touch code, and a seventh who reads and decides.

Launch six reviewers in parallel as subagents: architecture,
back-end, security, UX/UI, front-end and quality. Each reviews
the prototype from its own specialty, with PRD.md as the
reference, and writes its findings to reviews/<role>.md, ordered
from most to least serious, with a concrete proposal for each.
None of them modifies code. When they finish, act as product
manager and CTO: read the six reviews and write reviews/plan.md
in three lists — before publishing, after publishing, discarded —
with a one-line reason per item.

Then read plan.md. This is the moment your judgement is worth most: if the plan proposes adding things that are not in the PRD, say no. Mark what gets done and what does not, and close with /security-review on the changes before moving to §5.4.

Build, save, publish

Now. With the plan approved and the mode on accept edits:

Apply the items in reviews/plan.md marked "before publishing",
one at a time. After each one, check that the main journey still
works and propose a commit.

When the last commit is done, three services come in. All have a free account, and Claude drives them from the terminal; you create the accounts and give the go-ahead.

Two environments, not one

What separates a prototype from a product is not the code: it is that nobody tests in the place where the users are. From the first deployment there are two addresses, and everything goes through the test one first.

You ask for it once and it stays set up:

Set up two environments for this project: staging and production.
Staging publishes from the "staging" branch and production from
the "main" branch; neither changes without going through Git.
Each environment with its own environment variables and, if we
use a database, its own database: nothing in testing can touch
real data. When we have a domain, staging at staging.yoursite.com
and production at yoursite.com; until then, the two addresses
Vercel provides. Explain the flow for publishing a change before
you run anything.

Until you have your own domain, Vercel gives each environment an address; once you do, the test subdomain is assigned to the staging branch and the main one to main, and the flow does not change.

The order matters:

1. GitHub. "Create a private repository on GitHub for this project and push it." Claude uses gh (§4.6); if it is missing, ask it to install it. Check on github.com that .env did not go up.
2. The two environments on Vercel. The prompt above. When it finishes, Claude shows you two addresses and the flow: change → staging branch → staging → go-ahead → main branch → production.
3. Supabase, if needed. "Connect Supabase: create the tables PRD.md needs with row-level security on, one database per environment, and keep the keys in .env and in each environment's variables on Vercel, never in the code."
4. Automatic QA before publishing. Your own walk-through is necessary but not enough, so before each publish ask Claude to test for you: "Before publishing to staging, write and run automated tests for this project — unit tests for the logic and a smoke test that opens the site and walks the main journey. Do not publish if anything fails; show me the report." A smoke test is the shortest possible check that the thing basically works — the name comes from switching on a newly built machine and watching for smoke: does the page load, does sign-in work, does the main action complete? It runs in seconds and catches most of what breaks in a deployment. Claude writes these with a tool such as Playwright and keeps them in the repository, so from then on they run on every change without you asking.
5. The test in staging. Open staging.yoursite.com on your phone and do the whole journey with sample data: get in, do the thing, see the result — and also what should not work: an empty field, a skipped step, an address that does not exist. Whatever fails here goes back to §5.3. Nothing you see here has been seen by anyone else yet.
6. Production. "Staging is approved: publish it to production." Claude moves staging into main and Vercel publishes. Then the same QA pass again, this time against the live address: "Production is live: run the smoke test against yoursite.com and tell me if anything differs from staging." Repeat the journey yourself at yoursite.com — briefly, this time — and keep the link.

And after that: every improvement is the same cycle in miniature. A new line in the PRD, build, review, staging, production. What you set up in Part Four — context, skills, roles — is what makes the second round take half as long as the first.