Prompting and Workflows
The single biggest factor in how well Claude performs is the quality of your instructions. Not the length — the clarity. This chapter is about getting that right.
Better instructions get better results
Claude is not psychic. If your instruction is vague, Claude will make reasonable assumptions — and those assumptions might not be yours.
Compare these two:
Both are valid. The second one will produce something far more useful on the first attempt.
The rule: be specific about format, length, audience, and what to include or exclude.
When to be precise and when to leave it open
Precision matters for outputs that have a fixed shape — reports, summaries, structured documents. For those, give Claude the exact shape you want.
For exploratory tasks, leave it open. If you're asking Claude to look at a dataset and tell you what's interesting, don't over-constrain it. Let Claude find things you didn't think to look for.
Let Claude ask you the questions first
This is one of the most underused techniques. Instead of writing a long, detailed brief, let Claude interview you.
Claude will ask: What format are the exports? What categories matter to you? Do you want charts? Monthly or weekly view?
By the time the questions are done, Claude has everything it needs — and so do you.
This approach works especially well when you're not sure exactly what you want. The questions often help you figure it out.
Making sense of something unfamiliar
You've been handed a document, a codebase, or a dataset you don't understand. Start with orientation:
Then go deeper with specific questions once you have the lay of the land.
Building something from scratch
The pattern that works:
- Describe the end result you want
- Let Claude plan it with
/plan(Chapter 7) - Review and adjust the plan
- Let Claude build, one piece at a time
- Test as you go
Don't ask Claude to build everything in one shot. Break it into steps. Review each one. This keeps you in control and catches problems early.
Getting Claude's opinion before you commit
Before you buy a domain, pick a framework, or sign up for a service, ask Claude what it would choose. Give it the context — what you are building, what matters to you, what the options are — and ask it to reason through the tradeoffs and make a call.
This works better than a search because Claude reasons about your specific situation rather than returning generic results. The more constraints you give it, the more useful the output.
Same pattern works for choosing between two tools, picking a stack, deciding whether to use a library, or comparing two services. You are not asking for a list — you are asking for a reasoned recommendation.
Tracking down what is broken
If something isn't working:
Give Claude the error message, the relevant context, and what you expected to happen. The more specific you are, the faster it diagnoses.
If Claude gives you a fix and it doesn't work, don't just say "it's still broken." Paste the new error. Claude needs the updated information to keep diagnosing correctly.
Show Claude, don't just describe it
Some things are faster to show than to explain: a screenshot of an error, a photo of a receipt, a design you want copied, a chart you cannot read. Copy the image, then paste it straight into the prompt and ask your question.
On a Mac, paste images with Ctrl+V, not Cmd+V. Cmd+V pastes the file name as text. Ctrl+V pastes the actual picture. (On Windows it is Alt+V.)
Then ask as normal: "What is causing this error?" or "Build a page that looks like this screenshot."
Talk instead of type
You do not have to type at all. Turn on voice with /voice, then hold the Space bar and speak. Claude turns what you say into the prompt. For long or rambly instructions it is often faster than typing, and it helps if writing is not your thing.
You need a microphone and to be signed in. Voice is not available when you are running Claude on a remote machine.