Claude Desktop Fundamentals

Most people spend twenty minutes hunting for the right download link, sign into the wrong account, and wonder why their subscription features are missing. This lesson cuts that to under five minutes.

What you are installing

Claude Desktop is the native Mac and Windows application. It is not the same as claude.ai in a browser tab — the desktop app gets local file access, MCP server connections, and tighter OS integration that the browser cannot have. If you plan to use Projects or connect tools, the desktop app is where that work happens.

Walk-through

1. Go to https://claude.ai/download. The page detects your OS and shows one button.
2. On Mac: open the downloaded .dmg, drag Claude to Applications, and launch it from there — not from the Downloads folder. Launching from Downloads causes Gatekeeper warnings on some macOS versions.
3. On Windows: run the installer. It places a shortcut on the desktop and in the Start menu.
4. Sign in with the same email attached to your Claude subscription. If you use Google SSO on the web, use Google SSO here.
5. After sign-in, click your avatar in the bottom-left corner. Confirm the plan shows what you paid for (Pro, Team, or Max). If it shows Free, you signed into the wrong account.

If you get stuck

• "The app won't open on Mac" — Right-click the app in Applications and choose Open. This bypasses the first-launch Gatekeeper prompt. After that, double-click works normally.
• "I see the Free plan but I have Pro" — You have two accounts. Sign out, then sign in with the other email. If you are unsure which email is the paid one, check your subscription confirmation email.
• "The installer asks for an admin password on Windows" — Claude Desktop installs per-user by default, but some corporate machines restrict this. If you cannot install, ask IT to whitelist the app or use claude.ai in the browser for now.

Deliverable

Claude Desktop is open, you are signed in, and the plan badge in the bottom-left shows your paid tier. That one observable thing — the correct plan name — is the success criterion. If it is wrong, the rest of this course will work but you may hit rate limits or missing features.

The interface has more controls than a first glance suggests. Knowing where each one lives saves you from hunting mid-conversation when you need it.

What each element does

The model picker sits in the top-left of the chat input bar. It controls which Claude version handles your message. For most daily work, the default is fine. Switch to Opus when you need the model to hold a longer reasoning chain or handle a complex multi-step task; switch to Haiku when you need fast, cheap responses for high-volume work.

The attachment button (the paperclip icon) opens a file picker. You can also drag files directly into the chat window. Supported types include PDF, DOCX, TXT, images (PNG, JPG), and CSV. What the model can do with a file depends on the file type — it can read text from a PDF but cannot execute an Excel macro.

The "new chat" button (the pencil icon, top-right) starts a blank conversation with no memory of prior threads. Each chat is independent unless you are inside a Project, which carries persistent context.

The sidebar lists your recent chats. Starred chats pin to the top. You cannot rename a chat after the fact, so if you care about finding a thread later, star it immediately.

Walk-through

Open a new chat. Send one message — anything. Then:

1. Click the model picker and note the options available on your plan.
2. Drag a small text file into the chat window. Confirm the attachment thumbnail appears.
3. Star the chat using the star icon in the sidebar.
4. Click "new chat" and confirm the previous conversation is gone from the input area (it still exists in the sidebar).

If you get stuck

• "I do not see the model picker" — It appears only after you click inside the input field on some versions. Click the text area first.
• "My file attachment disappears after I send the message" — The attachment is embedded in the message. Scroll up; it is still there, just not shown in the input bar again.
• "I cannot find the chat I just had" — It is in the sidebar. If the sidebar is hidden, click the hamburger icon (three lines) in the top-left to expand it.

Cross-reference

When you are ready to give a chat persistent memory across sessions, see "Save what works as a Project" — that lesson turns a throwaway chat into a reusable workspace.

Deliverable

You have used the model picker, attached a file, starred a chat, and started a new one. The starred chat is visible at the top of your sidebar. That is the observable success criterion.

The first query most people send is a test — "write me a poem about coffee" or "what is the capital of France." That wastes the session. This lesson builds the habit of writing queries that produce something you could actually use today.

What makes a query useful

A useful query specifies three things on the first message: audience, format, and constraint. Audience is who reads the output — you, your manager, a customer. Format is the shape — bullet list, draft email, table, code snippet. Constraint is what limits apply — word count, tone, what not to include.

Without these three, Claude produces a generic middle. With them, it produces a first draft you can actually edit.

Walk-through

Pick one item from your actual inbox or task list right now. Something you would write anyway this week. Then build your query in this shape:

You are helping me [role/context].
Write [format] for [audience].
Constraints: [length], [tone], [what to omit].
Here is the input: [paste the raw material].

A real example:

You are helping me reply to a client who asked why a feature is delayed.
Write a two-paragraph email for a non-technical product manager.
Constraints: under 150 words, professional but not cold, do not mention the specific developer's name.
Here is their message: [paste].

Send it. Read the output. Note what is right and what is off. Then do one thing: send a single follow-up message that names exactly one thing to change. Not "make it better" — one specific change.

If you get stuck

• "The output is too generic" — You skipped the audience or the constraint. Add both and re-send.
• "I don't know what to ask" — Open your email and find the most recent message you have not replied to yet. That is your first query.
• "The follow-up made it worse" — That is useful data. Ask Claude to show you what changed between the two versions so you can see where the instruction was ambiguous.

Cross-reference

Once you have a query that works well, "One workflow you do every day" shows you how to save and standardize it so you are not rewriting it from scratch each time.

Deliverable

You have sent a query that produced a draft you could edit and send. The success criterion: you could copy the output into an email or document and make fewer than five edits before it was ready to use. If you needed more than five edits, the query was missing a constraint — go back and add it.

Pasting the wrong thing — a 40-page document when you needed one paragraph, or a snippet when you needed the full file — is the most common reason a response misses the mark. This lesson draws the line.

What "attaching" actually does

When you attach a file, Claude Desktop reads it into the context window for that conversation. The context window is not unlimited. Claude 3.5 Sonnet has a 200,000-token context window, which is roughly 150,000 words. A short PDF fits easily. A 200-page research report may not — or if it does, a very long document crowds out the rest of the conversation.

Pasting a snippet costs fewer tokens but requires you to paste the right part. If you are uncertain which part matters, attaching the whole file is safer.

When to attach versus paste

Attach the full file when:

• You are asking Claude to find something in a document and you do not know where it is.
• The file is small (under 20 pages, or under 5,000 words).
• You are in a Project with persistent context, where the file sits on the shelf and is reused across sessions.

Paste a snippet when:

• You know exactly which paragraph or function is relevant.
• You are in a one-off chat and do not need the rest of the file.
• You want to reduce token cost on a high-volume workflow.

Walk-through

1. Find a PDF or Word document you have used recently — a report, a spec, a contract.
2. Drag it into the chat window. Confirm the thumbnail appears.
3. Ask: "Summarize the three most important decisions in this document."
4. Now open a second chat. Paste only the section you consider most important (a few paragraphs).
5. Ask the same question.
6. Compare the two responses. Note which one was more precise and why.

If you get stuck

• "The file attachment fails with an error" — Check the file format. Claude Desktop supports PDF, DOCX, TXT, PNG, JPG, CSV. Formats like XLSX, PPTX, or ZIP are not directly supported; convert first.
• "The response ignores part of my document" — Very long documents can cause the model to weight the beginning more heavily than the end. Break the document into sections and ask about each section separately.
• "I cannot drag the file into the chat on Windows" — Use the paperclip icon instead. The drag target is the input field at the bottom, not the message area above.

Cross-reference

For documents that are genuinely too long to fit in one message, "Long documents and chunking" covers the mental model for breaking them up without losing coherence.

Deliverable

You have attached a file and received a substantive response that drew from the document content — not from Claude's general knowledge. The success criterion: the response quotes or paraphrases something specific from the file that you did not include in your question.

A 200-page PDF is not one prompt. Treating it as one is the reason responses about long documents feel shallow — the model is spreading attention across too much material. This lesson teaches the mental model for breaking a long document into manageable pieces without losing the thread.

What the context window actually limits

The context window holds everything: your instructions, the document, the conversation history, and Claude's response. If the document is very large, there is less room for everything else. More importantly, research on large language models consistently shows that retrieval accuracy degrades for content buried in the middle of a very long context. The beginning and end are retrieved more reliably.

This is not a bug to work around. It is a property to design for.

The chunking mental model

Think of the document in three layers:

1. Structure — table of contents, section headings, executive summary. Read this layer first. Ask Claude to map the document's structure before you ask about any content.
2. Target section — the chapter or section that contains what you actually need. Paste or attach only this section.
3. Cross-section synthesis — if you need to connect two sections (e.g., "how does the methodology in section 2 affect the conclusions in section 5?"), paste both sections in a single message with your connecting question.

Walk-through

Take a long document — a report, a spec, a lease. Do this sequence:

1. Paste the table of contents or first two pages. Ask: "What is the structure of this document and where would I find information about [your topic]?"
2. Open the section Claude points to. Paste just that section. Ask your actual question.
3. If the answer references something in another section, paste that section too and ask Claude to reconcile the two.

At no point do you need to paste the whole document. The three-step sequence gets you a more precise answer than dumping all 200 pages.

If you get stuck

• "I don't know which section to read" — That is what step 1 is for. Paste the structure and ask Claude to orient you.
• "The sections are long too" — Break the section into thirds. Paste the first third and ask your question; then paste the second third with "continuing from the previous paste." Claude will carry the thread.
• "I need an answer that spans the whole document" — Ask Claude to generate a structured set of questions you can answer section by section, then send it the answers. You become the retrieval layer; Claude does the synthesis.

Cross-reference

If you find yourself doing this kind of multi-session work repeatedly, "Save what works as a Project" shows how to keep the document on a persistent shelf so you are not re-attaching it every session.

Deliverable

You have extracted a precise answer from a document longer than 20 pages without pasting the whole thing. The success criterion: the answer Claude gave you contains a specific detail (a number, a date, a quoted phrase) that is verifiable by opening the source document and finding that exact detail in the section you pasted.

Claude Desktop is not Claude Code. Using the wrong tool for code work costs time and produces results that are harder to trust. This lesson draws the line so you do not waste a morning debugging something the wrong tool generated.

What Claude Desktop can do with code

Claude Desktop reads code, explains it, reviews it for logic errors, suggests refactors, and writes new functions. It does this entirely in text. It cannot run the code, it cannot browse your file system (unless you have added an MCP server that gives it access), and it cannot open a terminal. What you see in the response is a suggestion, not an execution.

This is useful for: code review, quick explanations, writing a function you will paste somewhere else, understanding an error message, or checking a regex before you ship it.

What Claude Code does differently

Claude Code runs in your terminal. It can read and write files, execute commands, run tests, and iterate on failures. If you need the AI to actually modify a file on disk and verify the change worked, that is Claude Code territory.

The test: ask yourself whether the task requires the file to change on disk. If yes, use Claude Code. If you only need text output that you will then act on yourself, Claude Desktop is fine.

Walk-through

Pick a function from a recent project — something under 50 lines. Paste it into Claude Desktop chat and ask two questions in the same message:

Review this function for correctness and readability.
Then suggest one refactor that would make it easier to test.

Read the response. Notice that Claude gives you a suggestion with an explanation, not a modified file. That is the right output from this tool. Now copy the suggested refactor and paste it back into your editor manually.

That sequence — ask, receive, decide, apply — is the correct workflow for Claude Desktop + code.

If you get stuck

• "Claude's suggestion broke something" — That is the expected risk of copy-pasting generated code. Always run your test suite after applying a suggestion. If there is no test suite, run the function manually with one known input before committing.
• "I need Claude to edit the file directly" — Install Claude Code (npm install -g @anthropic-ai/claude-code in your terminal, then run claude in the project directory). Claude Desktop cannot do this.
• "The response is too long and I lose track of the explanation" — Ask for a shorter response: "Review this function in under 100 words, then show the refactored version."

Deliverable

You have pasted a real function into chat, received a review with at least one specific suggestion, and applied that suggestion to the actual code in your editor. The success criterion: the modified function is in your editor and you can explain in one sentence what changed and why.

A prompt you write once and never save disappears the moment the tab closes. This lesson turns a one-off query into a saved, reusable workflow — something you can run tomorrow without starting from scratch.

What a workflow is, precisely

A workflow is a prompt with a stable structure that handles a class of similar tasks. Not "write an email" — that is too vague. "Write a status update email for a sprint that missed its goal, addressed to a non-technical project manager, under 200 words, professional tone, no blame language" — that is a workflow. It handles every sprint-miss email you will ever need to write, and the output is consistent enough that you can edit rather than rewrite.

The three components of a reusable workflow prompt:

1. Role context — what you are doing and who is reading the output.
2. Format spec — structure, length, tone.
3. Variable slot — the one thing that changes each time (the raw input).

Walk-through

Identify one task you repeat at least three times a week. Likely candidates: summarizing meeting notes, drafting a reply to a recurring class of request, generating a first draft of a ticket or spec.

Build the prompt:

Role: [what you are doing and for whom]
Format: [structure, length, tone]
Input: [paste the raw material here — this is the variable slot]

A concrete example for meeting notes:

Role: I am a product manager summarizing a 45-minute engineering sync for an executive audience.
Format: Three bullet points of decisions made, one bullet of open questions, one sentence on next actions. Under 150 words total. No jargon.
Input: [paste the transcript or rough notes]

Run this prompt three times on three different sets of notes. Refine it after each run — add one constraint if the output keeps getting something wrong.

If you get stuck

• "The output varies too much between runs" — You are missing a constraint. Each source of variation in the output maps to a missing specification in the prompt. Name the variation and add a rule for it.
• "I can't figure out what my repetitive task is" — Go through your sent email from the last two weeks. Find three emails that have the same basic structure. That structure is your workflow.
• "The prompt is getting too long" — That is fine. Long, precise prompts outperform short, vague ones for structured tasks. If the prompt exceeds what you want to type each time, the next step (saving it as a Project) solves this.

Cross-reference

The next lesson, "Debugging a prompt that almost works," covers what to do when your workflow produces the right output 80% of the time but fails on edge cases.

Deliverable

You have a written prompt that produces a usable first draft for a task you do at least three times a week. The success criterion: you ran the prompt on real input and the output required fewer than five edits before it was ready to use or send. Save the prompt text somewhere — a note, a doc, anywhere — before the session closes.

The 80% prompt is the hardest one to fix. You know it is wrong, but the output is close enough that you cannot immediately name what the instruction is missing. This lesson gives you three diagnostic moves that surface the missing constraint without guessing.

Why the 80% problem is hard

When a prompt fails completely, the failure is obvious. When it fails 20% of the time, you are tempted to conclude the model is unpredictable and there is nothing to fix. That conclusion is almost always wrong. The failure has a cause, and the cause is almost always a missing or ambiguous specification in the prompt.

The three diagnostic moves:

Move 1 — Read the failure, not the output

When the output is wrong, do not ask "what should the output have been?" Ask "what rule would have to be in the prompt to prevent this specific mistake?" The mistake is the diagnostic signal. A response that is too long means the prompt has no length constraint. A response that uses jargon the audience cannot understand means the prompt did not specify the audience's knowledge level.

Move 2 — Name the missing constraint

Write it in plain English before you add it to the prompt. "The output should never use bullet points — it must be prose." "The output should always end with a single action item." "The output should not include any information not present in the input." Once you can write the rule clearly, it will work in the prompt.

Move 3 — Test one change at a time

Add the new constraint. Run the same input that caused the failure. If the failure disappears, the constraint was the fix. If the failure persists, the constraint was not the cause — remove it and look for the next candidate. Never add two constraints in one round of testing; you will not know which one fixed it.

Walk-through

Take the workflow prompt you built in the previous lesson. Deliberately break it: remove one constraint. Run it on three different inputs. Find a failure. Then:

1. Write one sentence describing the failure.
2. Write one sentence stating the rule that would have prevented it.
3. Add that rule to the prompt.
4. Run the same three inputs again.
5. Confirm the failure is gone.

If the failure is gone, you have debugged the prompt. If it persists, go back to step 2.

If you get stuck

• "I can't tell what the failure is — it just feels off" — Ask Claude to critique its own output: "What is missing or incorrect in this response, given this prompt?" It will often name the constraint you forgot to include.
• "Every input produces a different failure" — Your prompt has too many variable slots and not enough structure. Add a format section that specifies the exact output shape before adding any other constraints.
• "Adding constraints makes it worse" — You are adding contradictory constraints. Read all the constraints aloud in order. If any two contradict each other (e.g., "be concise" and "cover every point"), resolve the contradiction explicitly.

Cross-reference

Once your prompt is stable, "Save what works as a Project" turns it into a persistent workspace that your teammates can use without seeing the prompt at all.

Deliverable

You have identified one specific failure in a prompt, named the missing constraint in one sentence, added it, and confirmed the failure no longer appears on the same input. The success criterion: you can run the prompt on an input that previously failed and the output is now usable without manual correction.

Further reading

• "Switch Channels, Don't Dig" — the three-strike rule: when iterating on a prompt that's almost working stops being productive, the answer is usually a different channel, not a tighter constraint.

A prompt that lives only in your head is a liability. This lesson turns the workflow you built and debugged in the previous two lessons into a Claude Project — a named workspace with a system prompt, attached context, and example outputs that any teammate can use without asking you what the prompt is.

What a Claude Project is

A Project is a named conversation environment with three persistent layers:

1. System prompt — instructions Claude reads at the start of every conversation in this Project, before you type anything.
2. Project files — documents attached at the Project level. They persist across sessions. You do not re-attach them each time.
3. Conversation history — prior conversations within the Project are accessible in the sidebar. You can reference them or start new ones that still inherit the system prompt and files.

A Project is not a saved chat. It is more like a configured tool: the settings stay constant while the conversations vary.

Walk-through

This is the hands-on portion. Budget 20 minutes.

Step 1 — Create the Project. In the Claude Desktop sidebar, click the "Projects" section and then "New Project." Give it a name that describes the workflow, not a generic name like "My Project." Example: "Sprint Status Emails."

Step 2 — Write the system prompt. In the Project settings (gear icon), paste your finalized workflow prompt as the system prompt. Remove the variable slot — that becomes the user's input in each conversation. The system prompt should be complete enough that someone who has never seen your prompt can use the Project and get correct output.

Example system prompt for the meeting notes workflow:

You are a product manager's assistant summarizing engineering syncs for an executive audience.

Always produce:
- Three bullet points of decisions made (each under 20 words)
- One bullet of open questions (if any)
- One sentence on next actions, naming the owner

Constraints:
- Under 150 words total
- No jargon (write as if the reader has no engineering background)
- Do not invent information not present in the input
- If the input is unclear, ask one clarifying question before producing the summary

Step 3 — Attach context files. If your workflow depends on reference material — a style guide, a glossary, a list of team members' names and roles — attach those files at the Project level now. They will be available in every conversation without re-attaching.

Step 4 — Test with a real input. Start a new conversation inside the Project. Paste a real input (meeting notes, an email, raw data). Confirm the output matches what you expect from the system prompt. If it does not, edit the system prompt and test again.

Step 5 — Share with a teammate. Open the Project settings and use the "Share" option to invite one other person by email. Ask them to run the Project on their own input without explaining the prompt. If they get correct output, the system prompt is self-contained. If they get confused, the system prompt has a gap — find it and close it.

If you get stuck

• "I don't see a Projects section in the sidebar" — Projects requires a Pro, Team, or Max subscription. If you are on Free, you can still save prompts as starred chats, but the persistent file layer and system prompt are not available.
• "The system prompt is being ignored" — Check for a conflict: if your conversation message repeats an instruction that contradicts the system prompt, the conversation message usually wins. Make the system prompt's constraints absolute ("always," "never") rather than suggestive ("try to," "prefer").
• "My teammate's output is different from mine" — Check whether they are in the same Project or in a new chat. Also check whether the model picker shows the same model version for both of you. Different models produce different outputs on the same prompt.

Deliverable

A working Claude Project with a system prompt, at least one attached context file, and at least one conversation that produced usable output without manual correction. The explicit success criterion: a teammate ran the Project on their own input, received output they could use without asking you for clarification, and did not need to see the underlying prompt to do so. That is the test. If they needed the prompt, the system prompt has a gap.

Further reading

• "What's on the Desk" — what it looks like when every morning's session starts with the working set already arranged, and the small system that gets you there.