Sign in with Google

How to Use Claude Effectively for Real Work

Projects for persistent context, long documents done right, and Artifacts you can actually iterate on.

beginner9 min read
ai-toolsclaudeai-literacyproductivitylearning-meta
If you use Claude the way you use a search box, you will get search-box results and conclude the hype was overblown. The things it is genuinely unusual at are the things a one-line question never touches: holding a 200-page document in view while you interrogate it, remembering your project's constraints across weeks of separate chats, and producing a draft you can then revise fifteen times without re-explaining anything. This guide covers how to set those up, what it is bad at, and the prompting style it responds to best.
iWhat you need
A Claude account. The free tier covers most of what follows, including web search, memory, and Artifacts. Paid plans — Pro, Max, Team, Enterprise — raise usage limits, add unlimited Projects and Research, and open up more models. Plans and limits change, so check what your account currently offers instead of trusting a list.
The current models — Opus 5 for complex work, Sonnet 5 for the best speed-to-capability trade, Haiku 4.5 when you want fast — carry very large context windows, which is the root of most of the practical advantages. Which models you can pick from depends on your plan.

Honest strengths and honest limits

  1. 1Strong: reading long material. Contracts, transcripts, research papers, a whole codebase file tree. It holds the thing in view rather than skimming a snippet.
  2. 2Strong: following long, explicit instruction sets. If you give it eleven numbered constraints, it will generally respect eleven numbered constraints.
  3. 3Strong: iterative drafting. Documents and small apps that you refine across many turns rather than accepting on the first attempt.
  4. 4Weak: anything it needs to look up and you have not given it. It does not know today's prices, your internal ticket numbers, or a library's current API unless web search is on or you pasted it.
  5. 5Weak: arithmetic-heavy and exact-count work done in prose. Ask for code that computes the answer instead of trusting a number it produced in a sentence.
  6. 6A real constraint: usage limits. A giant document in every message consumes your allowance quickly. Load it once in a Project instead of re-pasting it.
A Project is a workspace with its own chat history and its own knowledge base. This is the single feature most people skip and most regret skipping. The point is that you stop re-explaining your situation: the background lives in the Project, and every new chat inside it starts already informed.

Setting one up properly

  1. 1Create a Project per ongoing body of work — one client, one codebase, one course, one book you are writing. Not one per question.
  2. 2Add project knowledge: the style guide, the spec, the schema, the transcript, the previous three drafts. Files, pasted text, and code all work.
  3. 3Write custom project instructions. This is the highest-leverage box on the screen — say who you are, the audience, the conventions, and what you never want.
  4. 4On paid plans, a knowledge base that outgrows the normal limit switches to a retrieval mode that expands capacity substantially, so you can keep adding source material.
  5. 5On Team and Enterprise plans you can share a Project with view or edit access, which turns the instructions into a team standard rather than your personal habit.
✓Project instructions are where the leverage is
"You are writing for hospital procurement managers. They are not clinicians and not engineers. Never use the word 'solution'. Always give the cost implication before the technical detail." Three sentences like that improve every future chat in the Project more than any single clever prompt will.
Upload the real PDF, then do not ask it to summarize. "Summarize this" produces a competent, useless overview that tells you nothing you could not have guessed from the title, because you never said what you cared about. Ask questions only someone who read it could answer.
text
WEAK
Summarize this contract.

STRONG
I'm the buyer. Answer only from this document and quote the
clause number for every claim.

1. Under what conditions can they raise the price mid-term?
2. What happens to our data if we terminate in month 4?
3. Which obligations fall on us that a reader would miss on
   a first pass?
4. Where is the language vague enough to be argued either
   way? Quote it.

If the document doesn't address something, say "not
addressed" rather than inferring an answer.

The same 90-page contract, two ways of asking

Two details in there do most of the work. "Quote the clause number" makes every claim checkable in seconds, which turns the output into something you can audit rather than something you have to trust. "Say not addressed" gives it an explicit way out, which is how you reduce the pressure to invent a plausible answer to fill the gap.
When Claude produces something substantial and self-contained, it opens in a panel beside the conversation instead of scrolling past inside it. That includes documents, code, HTML pages, SVG images, diagrams and flowcharts, and interactive React components. The reason this matters is not presentation — it is that the thing now has an identity and a version history, so you can revise it twenty times without the chat becoming an unreadable pile of near-identical drafts.

How to work with them

  1. 1Ask for revisions conversationally — "make section 3 shorter and cut the second example" — and the panel updates in place.
  2. 2Use the version switcher to compare against an earlier draft. Getting worse across revisions is common and easy to miss without it.
  3. 3Markdown documents support editing in place, so you can fix a sentence yourself rather than describing the fix.
  4. 4Nothing is shared until you open the artifact and click Publish. Sharing is deliberate, not automatic.
  5. 5If artifacts do not appear at all, turn on code execution and file creation in Settings, under Capabilities.
Claude responds unusually well to explicit constraints stated as a list, and unusually badly to being trusted with taste it has no information about. Say the format. Say the length. Say the audience. And give it permission to admit uncertainty, which it will actually use.
text
You're helping me write release notes for a mobile app
update. Audience: existing users, non-technical.

Source of truth: the merged PR titles below. Do not
invent features that aren't in this list.
[paste PR titles]

Constraints:
- Max 5 bullets, one line each, user-visible benefit only
- No version numbers, no internal component names
- Lead with the fix people complained about most:
  the offline sync bug
- Plain register. No exclamation marks.

Output: a markdown artifact titled "Release Notes 4.2".

If a PR title is too ambiguous to turn into a user-facing
bullet, list it separately under "Need your input" instead
of guessing what it does.

A worked prompt with every part doing a job

That last paragraph is the part worth stealing. Giving a model a legitimate place to put its uncertainty is far more effective than telling it not to make things up, because "do not hallucinate" is an instruction with no action attached and "put it under Need your input" is one it can follow.
The default social pattern of any assistant is agreement, and agreement is worth nothing to you. The fix is to assign it the opposing job explicitly. Ask it to argue against your position as strongly as it can. Ask which single assumption, if wrong, breaks the whole plan. Ask what someone who disagreed with you would say first, and whether they would have a point.
Then read the objections as material rather than a verdict. Some will be generic and you can drop them. One or two will name the thing you had been avoiding thinking about, and that is the entire return on the exercise. This works far better before you have committed to a plan than after, which is exactly when it feels least necessary.
Large context windows tempt you into one enormous chat that carries a week of work. Quality degrades anyway, because half the context is now abandoned directions and superseded drafts. When a conversation has drifted, start a fresh chat inside the same Project and paste in only the current state — the accepted draft, the decisions made, the open question. The Project carries the background so you are not re-explaining anything.
!Some things do not go in the box
Do not paste credentials, API keys, or private keys — rotate anything you already have. Be careful with other people's personal data and with material you are contractually required to keep confined. Use an incognito chat for anything you want kept out of your history and memory.

Symptom, cause, fix

  1. 1Answers about your uploaded document are vague or slightly wrong. You asked it to summarize rather than to answer specific questions. Ask targeted questions and require quoted citations.
  2. 2It ignores a constraint you set three messages ago. Long conversations bury instructions. Move standing constraints into the Project instructions where they reload every chat.
  3. 3It keeps re-explaining your own background to you. Your Project instructions do not say who you are. One sentence about your role fixes the register permanently.
  4. 4You hit usage limits faster than expected. You are re-pasting the same large document in every message. Put it in project knowledge once.
  5. 5Artifacts never open, everything stays in the chat. Code execution and file creation is switched off in Settings under Capabilities.
  6. 6You shared an artifact link and the other person cannot see it. It was never published. Open the artifact and click Publish.
  7. 7The draft got worse over several revisions. This is normal and hard to notice. Use the version switcher and go back to the one that worked.
  8. 8It agreed with a plan that later fell apart. You asked for feedback, which invites agreement. Ask it to attack the plan instead.
The habits above are mostly prompting craft wearing a Claude-shaped hat, and How to Write Better AI Prompts covers the tool-agnostic version in more depth. If you write code, the terminal agent is a different animal entirely and worth learning on its own terms — How to Use Claude Code covers install, permissions, and scoping. Running the same task through a second assistant is a fast way to see what is model-specific and what is general skill, so How to Use ChatGPT Effectively pairs well with this one. And since most of the value here is asking better questions of dense material, How to Read Technical Documentation sharpens the same muscle without a model involved. For the full sequence, the Leveraging AI roadmap puts prompting, verification, and tool use in a sensible order.