Claude for people who have never used it

What Claude actually is (and what it isn't)

Claude is a large language model. That phrase will appear a lot, so it is worth defining once, slowly.

A large language model is a piece of software trained to predict what words tend to follow other words, across a very large amount of text. It is not a search engine. It is not a database. It does not "know" things the way a person knows things. It produces language that fits the pattern of what you gave it.

That sounds underwhelming. It is actually the entire point.

Because Claude works on patterns of language, it can do a wide range of things that look very different from each other — write a message, summarize a document, explain a concept, draft a plan, organize a list — using the same underlying skill. It is not a calculator that does one thing. It is a writer that can adapt.

What Claude is not

• It is not always right. It produces fluent, confident-sounding text whether or not the content is accurate. Confidence in its tone tells you nothing about correctness.
• It is not connected to the live internet by default. Unless you give it information, it works from what it was trained on — which has a cutoff date in the past.
• It does not remember you between conversations unless you set it up to. By default, every new chat is a stranger.
• It is not sentient and it is not your friend. It is a very capable text tool.

What Claude is, when used well

• A patient first-draft writer
• A reliable summarizer when you give it the source
• A second pair of eyes on a document, an idea, a plan
• A teacher that never gets impatient with you
• An assistant that does the boring parts so you can do the interesting parts

The chapters that follow are about how to set it up so this is what you actually get.

Why AI feels unreliable (and why that's a setup problem)

Most people's first experience with AI goes like this. They open it. They type a question. The answer is either surprisingly good or surprisingly off. They do not know why. They try a few more times. They get inconsistent results. They conclude that AI is "not there yet."

This is a reasonable conclusion based on the experience. It is also the wrong conclusion.

Every layer of computing in history has started this way. Punch cards in the 1800s were unreliable — they jammed, tore, misread. Early electronic computers in the 1940s were so error-prone that engineers had to invent something called error correcting code just to make memory trustworthy. Each new layer was rolled out, called unreliable, and then made reliable through engineering — not through waiting.

AI is the newest layer. It is being treated the same way. The instinct to say "I will use it once it is reliable" is the same instinct people had about every new computing layer for two hundred years. None of those layers became reliable on their own. They became reliable because people built the structure around them that made them reliable.

That structure is what this manual teaches.

When AI feels unreliable, the cause is almost always one of these:

• The setup is missing — you did not give it the information it needed
• The prompt is unclear — you asked it to do too many things at once, or did not say what "good" looks like
• The check is missing — you did not verify before acting on the answer

None of these are problems with AI. They are problems with how AI is being used. The good news: all three are fixable, and you can learn to fix them in an afternoon.

The folder is the brain — how to give Claude memory

Here is the single most important idea in this entire manual.

Claude has no memory of you between conversations unless you give it one.

By default, every chat starts blank. It does not remember your name, your work, your preferences, the project you were on yesterday, the rules you set up last week. This is the default behavior and it is a feature, not a bug — but it means that if you want Claude to actually be useful for ongoing work, you have to build its memory yourself.

The way you do this is with a folder. A plain folder, on your computer or in a tool that supports it, with a few text files inside.

Those files are the memory.

When you start a new conversation, you point Claude at the folder. It reads the files. Now it "remembers" — not because it has memory in the human sense, but because it has documents that tell it what it needs to know. Same effect.

This sounds almost too simple. It is genuinely the foundation. Everyone who uses Claude well does some version of this. People who don't, fight the same tool every day.

The folder structure looks like this in its simplest form:

your-project/
  CLAUDE.md         ← who you are, how you work, the rules
  CONTEXT.md        ← what you're working on right now
  REFERENCES.md     ← background info — people, links, definitions

Three files. Plain text. They will become Claude's brain for that project.

Chapter 4 walks through what goes in each one. The Appendix has copy-paste templates for all three.

The three-file workspace

Here is what goes inside each file. Keep them short. They are working documents, not novels. Full templates with example content are in the Appendix.

CLAUDE.md — the identity file

This is the always-on file. It tells Claude who you are, what you do, how you want to work, and any rules that should hold across every session.

It answers:

• Who am I? (your role, your background, your context)
• What is this project? (one or two sentences)
• How should Claude work with me? (preferred tone, response length, conventions)
• What should it never do? (rules, boundaries, things to flag instead of guess)

A good CLAUDE.md is between half a page and two pages. Anything longer and Claude will start ignoring parts of it.

CONTEXT.md — the current state file

This file changes often. It tracks what you are actually doing right now.

It answers:

• What am I working on this week?
• Where am I in the project?
• What decisions are open?
• What are the current open questions?

When you start a new session, you read this file too. It is the bridge between yesterday's work and today's.

REFERENCES.md — the background file

This file holds the things you do not want to retype every session.

• Names and roles of the people involved
• Definitions of terms specific to your work
• Links to source documents
• Standards or templates you reference often

This is the file Claude pulls from when something specific comes up.

Every session, point Claude at the folder. It reads the three files. You are now starting from a place where Claude actually knows enough to help.

A prompt is a form, not a question

Most people approach a prompt like a search engine query. They type a question and hope for an answer.

This is the wrong shape.

A prompt is not a question. A prompt is a form. It has fields. The fields have names. When you fill the fields well, you get a useful answer. When you leave fields blank, the model fills them in for you — and what it fills them with is often not what you would have chosen.

This idea has a long history in software. Every layer of computing — from the earliest programs in the 1800s to modern code — has worked the same way. You fill typed slots in a template. The slot has a name. The slot expects a certain kind of input. The output depends on what you put in.

A prompt to an AI works the same way. The slots are not visible by default — but they are there, and the model is filling them in regardless. Your job is to take control of what goes in each one.

The five slots are:

1. Identity — who Claude should be answering as
2. Task — what you want done
3. Context — what Claude needs to know to do it
4. Constraints — the rules and limits
5. Output Format — what the answer should look like

Chapter 6 explains each one. For now, the only thing to absorb is this: when your prompts feel inconsistent, it is almost never because the model is broken. It is because some of the slots are empty, and the model is guessing.

The five-part prompt

Here is the full shape, in order, with what each slot is for.

1. Identity — who Claude should be

You are giving Claude a role. The role shapes the answer.

"You are a senior copy editor reviewing a marketing email for clarity and tone."

This is not a personality trick. The role narrows what kind of language Claude pulls from. Asking the same question to "an editor" and to "a marketer" produces genuinely different answers. Pick the role that matches the work. Chapter 7 gives you 13 ready-made roles you can paste in.

2. Task — what you want done

One verb, one outcome. Not three things. One.

"Review this draft and list every sentence that is unclear, in the order they appear."

If you find yourself writing "and also" — stop. Save the second task for the second prompt.

3. Context — what Claude needs to know

Everything Claude needs that it does not already have. The actual draft. The audience. The constraints of the situation. The deadline if it matters.

Without context, Claude makes plausible-sounding guesses. With context, it makes grounded recommendations.

4. Constraints — the rules

What Claude must do, and what it must not do. Length. Tone. What to skip. What to flag instead of fix.

"Do not rewrite. Only flag. Keep flags under fifteen words each."

Constraints are the fence around the answer. Without them, the answer wanders.

5. Output Format — what the answer should look like

Not what to say — how to lay it out.

"Return a numbered list. Each item: the sentence, then the issue. No introduction, no closing summary."

Output format is what makes the answer usable. A great answer in the wrong shape is hard to use.

The rule of thumb: if your prompt is one sentence, you are probably missing four of the five slots. Two or three sentences is usually closer to right.

The Appendix has a copy-paste template for the full five-part prompt, plus six ready-to-use prompts for common tasks.

Thirteen personas to invoke

The Identity slot — the first one in the five-part prompt — is where you tell Claude who it should be answering as. Picking the right role narrows what kind of language Claude pulls from, and it changes the answer more than any other single move.

You do not have to invent a role from scratch every time. Below are thirteen personas that cover most of the work people actually do. Each one has a name, a one-line role, and a ready-to-paste Identity sentence. Click any persona to expand it.

Using personas well

• Use one persona per prompt. Mixing roles muddies the answer.
• Combine the persona with the other four slots. Identity alone is not enough.
• Adapt freely. These are starting points, not rules.
• Save the ones you use a lot. Paste them into your CLAUDE.md so they are always available.

The two kinds of constraints

The fourth slot — constraints — has more nuance than the others. It is worth a chapter on its own because most people only use one kind of constraint, and the other kind is where the real leverage is.

Format constraints

These are the obvious ones. They tell Claude what shape the answer should take.

• "Keep it under 100 words."
• "Use bullet points."
• "No greeting, no sign-off."
• "Respond in plain English, no headings."

Format constraints fix surface problems. They make the answer the right size and shape. They are necessary but not sufficient.

Strategic constraints

These are the quieter ones. They tell Claude how to think, not just how to write.

• "Do not invent any information that is not in the source below."
• "If something is unclear, ask before proceeding instead of guessing."
• "Flag anything that contradicts the brief — do not silently smooth it over."
• "Use only the information provided. If a fact is missing, say 'not specified.'"

Strategic constraints fix the deeper problems — hallucination, drift, overconfidence, made-up details. They are the difference between an answer that looks good and an answer that is actually trustworthy.

Format constraints make the answer usable. Strategic constraints make the answer reliable. You need both.

Most people add three format constraints and zero strategic ones. Then they wonder why the answer looks great but contains things that are not true.

Why your prompts hallucinate

A hallucination is when an AI confidently produces something that is not true. It might invent a quote, fabricate a fact, cite a source that does not exist, or describe a feature that the software never had.

For a long time hallucination was treated like a mystery — something inherent to AI that no one could fully control. That story has stopped being accurate. Hallucinations are now well understood, and almost all of them trace back to four specific prompting mistakes.

If you fix the four mistakes, hallucinations drop dramatically.

Mistake 1 — The vague prompt

No boundary, no source, no output format. The model fills the gaps with whatever seems plausible. Fix: define the role, the task, the source, and the format explicitly.

Mistake 2 — No source constraint

You ask Claude to "use expert knowledge" or you do not tell it where to draw from. It draws from training data, which may be outdated or wrong. Fix: give it a source, then say "use only the information below. If something is not specified, say 'not specified.'"

Mistake 3 — Too many tasks at once

You stack five instructions in one prompt. Research shows this makes inconsistent output far more likely — sometimes by an order of magnitude. Fix: one prompt, one task. Chain them sequentially.

Mistake 4 — Conflicting instructions

You ask for "concise but thorough" or "casual but professional." The model has to invent a middle ground that often contains neither. Fix: instructions should reinforce each other, not pull in opposite directions.

There is one more idea here that is worth holding onto:

Heavy AI users hallucinate more often than light users — because they build more complex prompts. Sophistication in prompting does not look like length. It looks like constraints.

A short, well-constrained prompt outperforms a long, loose one almost every time.

And one final warning: confidence is not accuracy. Current AI models are trained in a way that rewards confident-sounding answers. The model's tone tells you nothing about whether the content is correct. Always verify outputs that matter, through a human checkpoint or a second source. (Chapter 14 is dedicated to this.)

Why "one big prompt" never works

The first instinct most people have, once they get the hang of prompting, is to write longer prompts. If a five-line prompt works well, a thirty-line one should work better. Right?

Wrong, and the reason is structural.

Each task you add to a prompt multiplies the chance of inconsistent output. One task is reliable. Two tasks is mostly reliable. Five tasks is unreliable. The model is doing more things at once than it can keep coherent.

The fix is not "write a better one big prompt." The fix is to split the work into stages.

Each stage has:

• One clear job
• Its own short prompt
• A clear input and a clear output
• A check, before the next stage runs

This pattern is called a pipeline. It is the same pattern factories use, the same pattern software has used for fifty years, and the same pattern that makes AI workflows actually trustworthy.

A pipeline is slower to set up than one big prompt. It is much faster to run, much more reliable, and far easier to debug when something goes wrong. If the third stage produces a bad output, you know exactly which stage to fix.

The next chapter shows the simplest pipeline shape that works for almost any use case.

The five-folder pattern

The simplest pipeline shape that works for a wide range of work is five stages. Each stage gets its own folder. The folder name tells you what stage it is. Items move from one folder to the next as the work progresses.

01-receive/    ← raw input arrives here
02-filter/     ← AI sorts, scores, or triages it
03-process/    ← the main work happens — drafts, summaries, decisions
04-review/     ← a human checks the output
05-act/        ← the approved output is sent, posted, or saved

Why this works:

• Each stage has a single job. You can prompt it precisely.
• You can see, at a glance, how much work is in each stage. If 02-filter has 200 items and 03-process has none, you know where the bottleneck is.
• You can change one stage without breaking the others.
• A new person joining the work can understand the whole system in five minutes.
• When something goes wrong, you know exactly where.

You can adapt the names. A writer might use 01-ideas / 02-drafts / 03-edits / 04-review / 05-published. A small business might use 01-leads / 02-qualified / 03-proposed / 04-approved / 05-invoiced. The shape is what matters. Stages, with one job each, in order.

Most people who try to "use AI in their workflow" without this structure end up with one giant folder full of half-done things. The folders are not bureaucracy. They are how you stay sane.

You're not building AI — you're building the conductor

There is one last reframe to absorb before Part 3 ends, and it is the one that changes how you think about the whole project.

When you build a useful AI workflow, the AI itself is a small part of it. Most of the work is structure around the AI — folders, files, rules, checkpoints, the order in which things happen. People who study real production AI systems found that the breakdown looks roughly like this:

This is genuinely good news. It means you do not need to be a developer or a researcher to build something useful. The 90% of the work that matters is process design — and process design is something an organized, careful person can do without writing any code.

You are not building AI. You are building the conductor. The AI is one of the musicians. Your folders, your prompts, your rules — those are the score. The score works regardless of which orchestra plays it.

This also means your work is durable. Models change. New ones come out every few months. Tools come and go. But the structure you build — the folders, the staged pipeline, the rules about what gets checked — keeps working. You can swap one model for another underneath, and the system still runs.

You are building something that lasts longer than the tool you started with.

Always test on a copy first

This rule is short. It is also the rule that, when ignored, causes the most regret.

Whenever you are about to give Claude access to something real — a folder of files, a spreadsheet, a database, anything — make a copy first. Have Claude work on the copy. Verify the output. Only then touch the original.

People who skip this step almost always learn the lesson the hard way. A renamed folder that loses connections to other tools. A "cleaned up" spreadsheet that overwrote columns the team needed. A summary that replaced a master document instead of being saved separately.

These are not stories about AI being malicious. They are stories about AI being literal. You said "organize this." It organized it — its way. The original is gone.

The protocol is simple and worth treating as a rule, not a suggestion:

1. Make a copy of whatever you are working with.
2. Point Claude at the copy.
3. Verify the result is what you wanted.
4. Only then apply it to the real thing.

This adds one minute to your work. It saves you the day you lose three hours.

Confidence is not accuracy

This is the single most important habit you will build.

Claude — and every current AI model — is trained in a way that rewards confident-sounding answers. The model produces fluent, assured language whether the content is correct or not. There is no internal signal in the answer that tells you "I am unsure about this part."

This means: the tone of an answer is not a signal of its correctness. A confident wrong answer reads exactly like a confident right one.

Three habits protect you from this:

1. Always check anything that matters. If a decision will be acted on, the source must be verified. Not by Claude — by you, or by a second source that is not the same model.
2. Ask Claude to flag its own uncertainty. A simple line in your prompt — "If you are not sure, say so. Do not invent details." — produces noticeably more honest answers.
3. Build a checkpoint into your pipeline. Somewhere between Claude's output and the action being taken, a person looks at the result. Not to micromanage — to catch the things confidence hides.

The Appendix has a four-question verification checklist you can apply to any answer before you act on it.

You are not being paranoid. You are being grown-up about a tool that has a known weakness.

What you should never share with AI

This is the chapter no one talks about until something goes wrong.

When you paste text into an AI tool, you are sending that text out of your computer and into someone else's system. Depending on the tool and the plan, your input may be stored, logged, used to train future models, or visible to the company's staff under certain conditions. Not all tools handle this the same way. Read the terms of any AI tool before you put anything sensitive into it.

Below is a simple three-tier classification. Use it before every prompt.

●  Green  Safe to paste freely

• Public information you would be willing to share with a stranger
• Drafts, ideas, or content where the topic is general
• Test data you have made up
• Documents where every detail is fictional or already public

●  Yellow  Use care, redact when possible

• Internal team information that is not public but is not sensitive
• Names of colleagues (consider initials or roles instead, if their identity is not relevant)
• Project details that are not confidential but are not for outside eyes
• Process documentation
• Drafts of work that has not yet been published

For yellow material: ask yourself whether you actually need to include the sensitive parts. Most of the time you can do the task with the names redacted, the numbers fuzzed, or the source paraphrased.

●  Red  Never put in a prompt unless explicitly approved

• Personal data of others — full names with contact info, ID numbers, dates of birth, addresses
• Financial details — account numbers, card numbers, balances, salary information
• Health information — diagnoses, medical records, prescriptions
• Passwords, API keys, login credentials, security tokens
• Anything covered by an NDA, a contract, or a regulation (GDPR, HIPAA, financial compliance, professional confidentiality)
• Client confidential material
• Proprietary code, trade secrets, or unreleased product information
• Anything you would not want to read on a public forum tomorrow

If you would not paste it into a public web search, do not paste it into an AI prompt — unless you have verified the tool's data handling and your organization has approved it for that level.

A few extra habits worth building:

• Use a separate "scratch" account or workspace for personal exploration, separate from any work account.
• When you must use real data, anonymize first. Replace names with letters, dates with placeholders, numbers with something obviously fake. Run the prompt on the anonymized version. Substitute the real data into the answer afterward yourself.
• Watch for screenshots. A screenshot can leak data even if you would never type that data. Crop carefully.

Keep a record

The single habit that saves you when something goes wrong is keeping a record of what Claude did.

This sounds bureaucratic. It is not. It is forty-five seconds of typing per session that means future-you can retrace what was done, prove what was changed, and hand the work off to someone else without re-explaining.

Why a record matters

• You can retrace what was modified — and roll it back if needed
• You can prove what was done if asked (by a colleague, a manager, an auditor)
• You can spot patterns in your own mistakes over time
• You can hand work off to someone else without re-explaining the history
• You can catch a problem early, before it propagates

What to log, every session

• The date
• What you asked Claude to do (a sentence is enough)
• What it produced (a copy, a snapshot, or a summary)
• What you decided to keep, change, or discard
• Anything you flagged as wrong, surprising, or worth checking later

Three lightweight ways to keep a record

1. A LOG.md file in each project folder. Append a few lines after each session. Date, prompt, decision. That is enough.
2. A spreadsheet with one row per session. Useful if you want to see patterns across many sessions.
3. A folder structure that timestamps the work. For example, 02-filter/2026-05-03_inputs/ and 02-filter/2026-05-03_outputs/. The folders themselves are the log.

You do not need formal documentation. You need enough breadcrumbs that future-you can retrace today's work.

Never let Claude take an action that you cannot retrace. If you would not be able to explain afterward what was done and why, you should not be doing it yet.

Backups, boundaries, things you don't let Claude touch yet

A short list of habits that keep you out of trouble. None of them are advanced. All of them get skipped.

Back up before you let Claude do anything significant

The first time Claude reorganizes a folder, runs a script, or modifies multiple files, the original state should be saved somewhere safe and easy to restore. This is not paranoia. It is normal hygiene for any tool that takes action.

Do not put sensitive data into a tool that does not promise to protect it

Read the terms of the AI tool you are using. Know whether your inputs are stored, whether they are used to train future models, and whether other users could ever see them. (See Chapter 15 for the full classification.)

Decide in advance what Claude is not allowed to touch

Make this a clear list and put it in your CLAUDE.md so the rule is always loaded. Examples that work for most people starting out:

• Anything that sends a message externally without you reading the final text first
• Anything that deletes files
• Anything that modifies access permissions or sharing settings
• Anything that posts publicly (social media, forums, public documents)
• Anything that triggers a payment or a transaction
• Anything that renames files or folders that other tools depend on
• Database operations that change or remove data
• Anything that contacts a third person on your behalf
• Anything you cannot undo with one click

Keep a human in the loop for anything irreversible

"Irreversible" is the key word. If a step cannot be undone, a human approves it. No exceptions, no shortcuts, no "it will be fine." This is not about distrusting AI. It is about respecting that some actions cannot be taken back.

Review your setup every few months

What you trusted Claude to do six months ago and what you trust it to do now should not be the same list. The tool changes. Your judgment about it should too. Put a recurring reminder in your calendar.

These habits feel slow when nothing has gone wrong. They are the reason nothing has gone wrong.

You do not have to do all of this. You should not even try.

The mistake almost everyone makes after reading something like this is trying to apply all of it on Monday. They build the folder, write the CLAUDE.md, design the pipeline, draft every safety procedure, and burn out by Wednesday.

Here is the only thing you have to do tomorrow:

Pick one task you do every week. Make a folder for it. Add a CLAUDE.md file using the template in the Appendix. Open Claude. Point it at the folder. Try one prompt — with all five slots filled, and one of the thirteen personas as the Identity — to do part of that task.

That is the entire assignment. Nothing else.

If it works, do it again the next day with the same task. Refine the prompt. Add a second file if you need it. Notice what changes.

If it does not work, look at the four hallucination mistakes from Chapter 9. One of them will apply. Fix it. Try again.

After two weeks of doing this with one task, you will have built more usable AI infrastructure than most people have in production right now. Without ever calling it that. Without writing a line of code. Without anything that looks like a project.

This is how it actually happens.

The folder is the brain. The prompt is a form. The persona is the role. The pipeline is the conductor. The check is what keeps you safe. The record is what keeps you accountable.

You have everything you need.

The Appendix below is a kit. Use the templates. Skip what you don't need yet. Come back when you do.