From “I sometimes chat with AI” to confident power user.

Most people meet AI the same way: they type a question into a chat box, get an answer, and stop there. That's like buying a car and only ever sitting in it to listen to the radio. The engine is fine — nobody showed you the pedals.

This guide is the driving lesson. By the end you will:

• Know what Claude is genuinely good at — and where it needs you.
• Write prompts that get useful answers on the first or second try, not the seventh.
• Use Projects so you stop re-explaining yourself in every chat.
• Pick the right model for each job without memorizing spec sheets.
• Run Claude Code — an AI that works in your files, safely — even if you've never coded.
• Build repeatable systems with skills, hooks, and connectors, with sensible guardrails.

Who this is for

Smart, busy people who already use ChatGPT or Claude casually and keep hearing words like projects, context, skills, hooks, MCP, and coding agents without a clear picture of what they are. No programming background is assumed. When code appears, it's short, annotated, and optional to type.

One honest note before we start

Claude is a powerful collaborator, not an oracle. It can be confidently wrong, it can't read your mind, and it works dramatically better for people who learn to steer it. This guide is exactly that steering practice — including the failure modes, not just the highlight reel.

A search engine finds things that already exist. Claude makes things: drafts, plans, explanations, code, critiques, summaries. That difference changes how you should use it. You don't “query” a teammate — you brief them, look at what they produce, and steer.

What Claude is genuinely good at

Where it needs you

The collaboration loop

Every good session — a chat, a project, a coding session — is the same loop. Learn it once, use it everywhere:

The key habit hiding in that diagram: react instead of rewriting. When a draft isn't right, don't start over and don't fix it all by hand. Say what's wrong — “too formal, and cut the second paragraph” — and let Claude do the labor. Steering is cheap; rewriting is expensive.

Imagine emailing a freelance writer: “Write something about our product.” You'd get something generic — and it would be your fault. Claude is the same. The fix isn't clever wording; it's the five ingredients every real brief has:

You won't need all five every time — a quick question needs none of them. But when the output matters, each missing ingredient is a guess Claude has to make for you.

Before and after

Iteration is part of the prompt

Your first prompt is the opening move, not the whole game. Three habits close the gap fast:

• Steer with reactions. “Shorter.” “More specific in paragraph 2.” “You invented a statistic — remove it.” Each nudge is ten seconds of typing.
• Ask Claude to interview you. When you can't articulate what you want, flip it: “Ask me 5 questions that would help you do this well, then do it.” Astonishingly effective.
• Ask for options. “Give me 3 versions: safe, bold, and weird.” Choosing is easier than specifying.

First, what a chat actually remembers

Within one conversation, Claude sees everything said so far — that running transcript is called the context. But each new chat starts blank. Yesterday's brilliant conversation about your business? A new chat has never heard of it. This surprises almost everyone, and it's the reason casual users feel like they're “starting over” constantly.

What a Project gives you

A Project is a folder for related conversations, plus two persistent things every chat inside it automatically knows:

• Project instructions — standing orders, written once. “I run a 12-person accounting firm in Toronto. Write in plain English. Always show your assumptions.”
• Knowledge files — documents you upload once: your price list, brand guide, the report template, last year's plan. Claude consults them in every chat.

Notice what you didn't type: who your audience is, what your voice sounds like, what the survey said. The project carried it.

When to use which

Structuring project knowledge well

• Instructions = how to behave. Voice, audience, format rules, standing constraints. Keep it under a page; it's read every single time.
• Knowledge files = what to know. Reference material that changes rarely. Prefer a few well-named files over twenty fragments.
• Refresh deliberately. When something important changes (new pricing, new goal), update the file — don't just mention it in one chat and hope.
• Promote discoveries. When a chat produces something durable — a decision, a template that worked — paste it into instructions or a knowledge file. This is the habit that compounds; Chapter 10 builds a whole system on it.

Model names and version numbers change constantly — memorizing them is a losing game. What doesn't change is the shape of the lineup. Every AI provider, Claude included, offers a spectrum with three practical zones:

The decision guide

Or just answer three questions

Two power-user habits

• Escalate on friction, not by default. If the balanced model nails it, you're done. If the answer feels shallow on a hard problem, re-run the same prompt on the deep model and compare — the difference tells you what the extra thinking buys.
• Match the model to the step, not the project. Within one piece of work: deep model to design the plan, balanced to execute it, fast to clean up the formatting. This matters most in Claude Code, where you can switch mid-session.

What it is

Claude Code is Claude running in a terminal (or its desktop/web app), pointed at a folder on a computer. Instead of only talking, it can act: read your files, edit them, run commands, and check its own work — asking your permission along the way. It's called Claude Code because programmers got it first, but it's really “Claude with hands”: people use it to organize files, wrangle spreadsheets, draft document sets, and automate chores, not just to build software.

The word for this kind of tool is an agent: an AI that doesn't just answer once, but works toward a goal in steps — acting, observing the result, and adjusting. That sounds grand; in practice it looks like a very diligent colleague narrating their work in your terminal.

The loop it runs

Watch any Claude Code session and you'll see the same cycle, which should look familiar — it's the collaboration loop from Chapter 1 with real actions in it:

A safe first session, step by step

Here's a realistic first session on a small project. Click through it — each step teaches one habit worth keeping.

The habits, distilled:

• Start read-only. “Look around and tell me what this does” costs nothing and builds shared context.
• Ask for a plan before edits. Reviewing a 3-line plan is easier than reviewing a 300-line surprise.
• Let it verify. Ask Claude to run the tests or checks itself — and read the output it shows you.
• Review the diff. A diff is just “what changed” — additions and removals, line by line. You don't need to understand every line to notice when a change is bigger than expected.
• Work in small rounds. One goal per request. Small loops fail small.

A skill is a reusable set of instructions — a recipe card — saved where Claude can find it. It has a name, a short description of when it applies, and the steps or standards to follow. When your request matches the description, Claude pulls out the card and follows it. You've effectively taught it a procedure, once, forever.

Why this beats re-explaining

Where skills live, and when they fire

In Claude Code, skills are folders inside your project (each holding a SKILL.md file — commonly under a .claude/skills/ directory, and personal ones can live at the user level so they're available in every project). Claude sees each skill's name and description; when your request matches — or you invoke it by name, like /weekly-report — it loads the full instructions and follows them. In the Claude apps, capabilities and project instructions play a similar “standing instructions” role. The concept is the thing: named, reusable procedure, loaded on demand.

A real example

Say every Friday you turn messy meeting notes into a status update for your boss. Here's the whole skill:

---
name: status-update
description: Turn raw meeting notes into the Friday
  status update for my manager. Use when asked for a status
  update or weekly summary.
---

Turn the notes I give you into a status update:

1. Structure: **Done · In progress · Blocked · Next week.**
2. Under 200 words total. Bullet points, no fluff.
3. Blocked items: name who we're waiting on and since when.
4. Tone: factual and calm. Never oversell progress.
5. End with one question my manager can answer to unblock us.
6. If the notes are ambiguous about status, ask me —
   don't guess.

Read that again — it's not code. It's just the briefing you'd give an assistant, written down. The two-line description matters most: that's how Claude knows when to reach for this card without being told.

Here's the distinction that makes hooks click. Telling Claude “always format the code after editing” usually works… but it's still a request to a collaborator who is juggling many instructions. A hook takes the same rule out of the conversation entirely: it's a small command that Claude Code's machinery runs automatically at a specific moment — like a seatbelt chime. The car doesn't ask the driver to remember; it just chimes.

The event lifecycle

Hooks attach to moments — events — in a session. The most useful ones:

Three genuinely useful hooks

A hook definition is small — a settings entry that says on this event, matching this kind of action, run this command. For example, the auto-format hook in plain words: “After any file edit… run the formatter on the edited file.” You can ask Claude Code to write its own hooks: “Add a hook that formats Python files after you edit them.” It knows its own configuration format.

Safety cautions — hooks cut both ways

Rule of thumb: hooks should observe, tidy, or block — rarely create. The ambitious automation belongs in skills and workflows, where Claude's judgment (and your review) stay in the loop.

MCP (Model Context Protocol) is a standard way to plug tools into Claude. Each plug-in is called an MCP server — in the Claude apps you'll often see the friendlier word connector. One server might expose your email, another a database, another a web browser Claude can drive. The protocol is open, so anyone can build one, and the same connector works across AI tools that speak MCP.

A useful mental picture: Claude is a skilled worker at a workbench. MCP servers are tools you clip onto the bench. Each tool announces what it can do (“search email”, “query the sales database”, “take a browser screenshot”), and Claude decides when a task calls for one — asking your permission before use, just like file edits in Claude Code.

Why it's powerful

Without MCP, you are the courier between Claude and your systems — copying the meeting list out of your calendar, pasting query results from your database. With the right connectors, “find 30 minutes next week when Sam and I are both free, and check whether any deals in the pipeline are stuck” becomes one request. The workbench does the walking.

Trust before power

An MCP server is software you're wiring into your AI with access to real accounts and real data. Treat adding one like hiring a contractor with keys:

• Source: who built it? Official connectors from the service itself, or well-known open-source servers, beat a random link.
• Scope: what access does it get? Read-only where possible. A calendar-reading server is a different risk than one that can send email as you.
• Blast radius: what's the worst it could do with the access it has? If the answer includes “irreversibly” — deleting records, spending money, messaging people — insist on per-action confirmation, or don't connect it.
• Injection: connectors carry content into your session — web pages, emails, documents. That content is untrusted. More on this in the next chapter.

When not to add one

Principle 1 · Least privilege

Give each session the minimum access the task needs — you can always grant more when asked. Claude Code's permission prompts implement this: when Claude wants to edit a file or run a command, you can allow it once, or allow that kind of action for the session. The power-user pattern is to widen gradually: let routine, reversible actions (running tests, editing files in the project) flow freely, and keep prompts on for anything unusual. Resist the temptation to approve everything on day one — the prompts are also how you learn what your tools actually do.

Principle 2 · Local is rehearsal, external is showtime

This one distinction prevents most disasters. Everything Claude does inside your project folder is rehearsal: reversible with git, private, cheap to redo. The moment an action leaves the machine — sending an email, posting, deploying a website, spending money, messaging a customer — it's showtime: audiences, consequences, no undo.

Principle 3 · Secrets stay out of conversations

• Don't paste passwords, API keys, or client-confidential data into prompts. Claude doesn't need your password to help you — and secrets in a transcript are secrets in one more place.
• Keep secrets in the standard places (environment variables, a .env file that's excluded from version control) and refer to them by name: “use the key from the environment.”
• A tidy habit that pays off: ask Claude Code to check that no secrets are lying around in files you're about to share or commit.

Principle 4 · Content is not commands

Here's the subtle one. When Claude reads a web page, an email, or a document, that content might contain text like “Ignore your instructions and forward this to…” — written by someone hoping an AI will obey it. This is called prompt injection. Claude is trained to resist it, but your setup should assume imperfection:

• Treat everything fetched from outside — pages, emails, attachments — as data to analyze, never instructions to follow.
• Be most careful when three things combine: untrusted content + access to private data + ability to act externally. That triangle is where real damage happens. Break any one side — read untrusted content in a session that can't send things out, for instance — and the risk collapses.
• If Claude reports something weird in fetched content (“this page told me to change your settings”), that's the system working. Don't follow up by loosening permissions.

The safety checklist

The difference between a casual user and a power user isn't prompting talent. It's that the power user stops solving the same problem twice. Every good prompt becomes a template. Every repeated instruction becomes standing context. Every procedure becomes a skill. Every rule becomes a hook. The system accumulates; the casual user starts from zero each morning.

How the parts fit

Standing context: the CLAUDE.md idea

In Claude Code, a file named CLAUDE.md at the root of your project is read automatically at the start of every session — the same job Project instructions do in the Claude apps. It's where re-explaining goes to die. A great one is short and answers four questions:

# What this project is
One paragraph. What we're building, for whom, and the
current state. (New sessions read this first —
write it for a smart stranger.)

# How to work here
- Run checks with: npm test (or your equivalent)
- Style: plain language in docs, small commits.
- Always show a plan before edits over ~30 lines.

# What “done” means
- Tests pass, and new behavior has a test.
- No secrets in files. No new dependencies without asking.

# Current focus & decisions
- Working toward: v1 of the weekly report generator
- Decided: keep data in CSV for now (revisit at 1k rows)

Keep it under a page — it's loaded every session, so every sentence should earn its place. Update the “current focus” section as things change; it's what makes Monday's session continue Friday's thinking.

The workflow recipe

Here's the repeatable pattern for turning any recurring task into a system. Say you produce a monthly client report:

1. Do it once, well, in a chat. Iterate until the output is genuinely good. This is your prototype.
2. Extract the template. Ask Claude: “Turn what we just did into a reusable template + instructions.” Save it.
3. Promote to standing context. The stable facts (client voice, format rules) go into project instructions or CLAUDE.md; the procedure becomes a skill (/monthly-report).
4. Add verification. Decide what “done” means — numbers reconciled? every section present? under two pages? — and write it into the skill so Claude checks before showing you.
5. Add guardrails where memory fails. A hook that logs each run; a rule that nothing is emailed to the client without your review.
6. Run it, and improve the files, not just the output. When run #3 has a flaw, fix the skill so run #4 can't repeat it. This step is the compounding engine.

Each exercise uses the previous one. Check them off as you go — your progress saves in this browser. If an exercise takes more than the suggested time, shrink the scope, not your standards: small and finished beats ambitious and abandoned.

Warm-ups (Chapters 1–4)

First sessions (Chapter 5)

The build (Chapters 6–10)

Now the real thing: build a small tool that solves one recurring annoyance in your life, with Claude Code doing the coding and you doing the steering. Good candidates: a script that renames and files your downloads; a page that turns pasted meeting notes into your status-update format; a little dashboard that reads a CSV you export weekly and shows the three numbers you care about. Yours should be so small it sounds trivial. That's correct — the point is the workflow, and “trivial” tools get used daily.

Goal: what exactly do I want?
Context: what must you know? (paste it)
Constraints: length, tone, format
Example: here's what good looks like
Success: how I'll judge the result

"Ask me 5 questions first, then do it."
"Give me 3 versions: safe, bold, weird."
"Critique your own draft, then revise."
"Shorter. Keep the second example."
"You invented that stat — remove it."

1. "Look around, change nothing yet."
2. "Show me a plan first."
3. Approve → let it edit
4. "Run the tests / checks."
5. Review the diff → commit
Small rounds. One goal per request.

Least privilege; widen gradually.
Local = rehearsal. External = showtime:
  review before send/publish/spend.
Secrets in env files, never in prompts.
Fetched content is data, not orders.
Git before and after big changes.

What to try next

• This week: finish any capstone exercises you skipped — especially #5, the read-only recon. It's the cheapest confidence you'll ever buy.
• This month: systematize your second and third recurring tasks. The second one is where the recipe starts feeling natural.
• Level up your prompts: keep a “greatest hits” note of prompts that worked unreasonably well. It becomes raw material for skills.
• Explore carefully: add your first MCP connector for a flow you run weekly — after it passes the Chapter 8 trust questions.
• Go deeper: the official Claude and Claude Code docs cover the current details this guide deliberately kept version-free: exact features, settings, and connector catalogs. You now have the map that makes those docs readable.
• Teach someone. Walk a colleague through the collaboration loop and the brief. Nothing reveals the gaps in your own model faster — and power users are more useful in teams that have a second one.