How to Write Effective Prompts for Claude (Part 1)

If you give Claude a vague instruction, it rarely produces a useful result. It's like asking a colleague to "take care of that thing." You'll get something, but it's rarely what you need. The solution is to provide enough context: give Claude the information it needs to produce a good result.

By the end of this guide, you'll:

• Understand what a prompt is and why context changes the output.
• Know how to give Claude instructions to perform a task for you.
• Know how to give Claude instructions to work something out together.

What is a prompt, and why does context matter?

A prompt is the instruction you give Claude. It's either a short question, like "Translate this sentence," or a brief: an instruction carrying the context that shapes the result. Claude reads it and answers based on what you gave it.

Writing instructions is the whole skill, and it doesn't stop at the chat box. A prompt, a skill, an automated task, an agent: each is a set of instructions at a larger scale. That's why prompting comes first: it's the foundation the rest builds on.

Most prompts fail because they're vague. "Write me an email" tells Claude nothing about the purpose, the reader, the tone, or the length. So it guesses, and you get something generic.

A brief fixes this. What it adds is context: who it's for, what to use, what a good result looks like. Give Claude that and you won't be asking for changes three times. The rest of this guide gives you two ways to write one.

Two kinds of prompts

Do you want Claude to carry out a task, or to work something out with you? Your goal decides the kind of prompt.

Most work is the first kind: reply to an email, draft a summary, analyze a process. Frameworks handle these. The second kind is rarer but harder: a problem statement, a value proposition, a plan. That's where wizard prompts earn their place. We'll start with frameworks.

Framework prompts: get a task done

Handing over a task so someone delivers exactly what you need is one of the hardest management skills there is. A framework makes it easier: it spells out what belongs in the brief. Cover its components and Claude has enough to work with. You also get better at briefing people. Pick one based on the task:

These are starting points, not rules. Combine, expand, or trim them as the task needs.

R-T-F

R-T-F stands for Role – Task – Format and is best for short, straightforward tasks:

• Role: what role should Claude take on?
• Task: what task should it perform?
• Format: how should the output be delivered?

Example

To reply to an email, you could use the framework like this:

<role>
Personal assistant.
</role>

<task>
Write a reply to this email regarding [subject/purpose].
</task>

<format>
- A ready-to-send email reply.
</format>

In practice, Claude often needs extra context to get a good result. With a <context> tag, you can attach the email to your prompt:

<context>
Use the attached file:
- [file name email]
</context>

Or include the full email inline:

<context>
See the email below:
[email]
</context>

To get an even better response, add the desired reading level. The prompt could then look like this:

<role>
Personal assistant.
</role>

<task>
Write a reply to this email regarding [subject/purpose].
</task>

<context>
Use the attached file:
- [file name email]
</context>

<output>
<format>
- A ready-to-send email reply.
</format>

<language level="B1">
These rules apply to the *entire* text below:

* **Language:** Flawless English (US-EN).
* **Level:** Strictly B1 (simple, concrete, understandable).
    * One main idea per sentence, maximum.
    * One subordinate clause, maximum.
* **Tone:** Clear, professional, and human.
  Address the reader as "you" in a [CHOOSE: conversational / formal] register.
* **Sentence structure:**
    * Short, active sentences (15 words maximum).
    * Prefer the active voice. Avoid the passive voice where possible.
    * **Avoid convoluted, interrupted constructions and nominalizations.**
* **Word choice:**
    * No abstract jargon (such as *implement*, *facilitate*).
    * No buzzwords.
* **Form:**
    * **Start each paragraph with the key sentence.**
    * Write in flowing prose.
    * No lists of keywords, unless explicitly requested.
    * Use white space for readability.

* **Check (required):**
    * Before output, check:
        * Does every sentence meet B1?
        * After reading, does the reader know exactly what to do?
</language>
</output>

For the full set of reading levels (A1–C2) as ready-made components, grab the language levels reference. To keep the structure clear, the <format> tag sits inside <output>.

Tip: Structure your prompts with XML tags: one tag per component (<role>, <task>, and so on). Claude is trained to key off them, so it reads the structure more reliably.

R-A-C-E

R-A-C-E stands for Role – Action – Context – Expectation:

• Role: what role should Claude take on?
• Action: what action should it perform?
• Context: what background does it need to perform the action well?
• Expectation: what is the expected result?

This framework suits Claude tasks like:

• writing emails
• writing advisory or explanatory texts
• creating marketing and communication materials
• writing messages for colleagues or customers

Example

To write a short explanation of a new way of working, you could use the framework like this:

<role>
Internal communications advisor.
</role>

<action>
Write a short explanation of the new leave-request procedure.
</action>

<context>
The procedure changed to simplify the process and prevent errors. The audience is colleagues with no HR background.
</context>

<expectation>
- Makes clear what changed
- Explains what colleagues now do differently
- Answers frequently asked questions and prevents misunderstandings
- Keeps an accessible, professional tone
</expectation>

With R-A-C-E you steer mainly on content, audience, and intent. You can improve this prompt by adding extra context and instructions, such as placement, length, and reading level:

<role>
Internal communications advisor.
</role>

<action>
Write a short explanation of the new leave-request procedure.
</action>

<context>
Use the attached policy document as your source, and base the explanation only on the information in it:
- [policy document file name]

Audience: colleagues with no HR background.
Goal: simplify the process and prevent errors.

Explicitly include the following (take them from the policy document):
- Effective date of the new procedure
- Where colleagues request leave (system/portal) and what no longer applies
- Minimum notice period
- Who approves and what the turnaround time is
- Where colleagues can go with questions (contact point/link)

If information is missing from the policy document, say so explicitly and do not make assumptions.
</context>

<expectation>
The explanation:
- makes clear what changed
- explains what colleagues now do differently
- anticipates likely questions and prevents misunderstandings
- keeps an accessible, professional tone
</expectation>

<output>
<placement>
[intranet message / Teams post / email to all staff]
</placement>

<length>
[e.g. 120–160 words]
</length>

<structure>
- 1 short intro (what and why)
- 3 bullets (what's changing + what you need to do)
- 1 closing line with a call to action (where to arrange it / where to find help)
</structure>

<language level="B2">
These rules apply to the *entire* text below:

* **Language:** Flawless, natural English (US-EN).
* **Level:** B2 (fluent and persuasive).
    * Nuance and well-supported opinions are allowed.
* **Tone:** Professional, engaged, and persuasive.
  Address the reader as "you" in a [CHOOSE: conversational / formal] register.
* **Sentence structure:**
    * Varied sentence length (15–20 words on average).
    * A mix of main and subordinate clauses for a natural cadence.
    * The passive voice is allowed, if functional and not excessive.
    * **Avoid convoluted, interrupted constructions and nominalizations.**
* **Word choice:**
    * Rich vocabulary.
    * Abstract concepts are allowed, if clear in context.
    * Technical terms are allowed, in moderation.
* **Form:**
    * **Start each paragraph with the key sentence.**
    * Well-structured paragraphs.
    * Flowing prose.

* **Check (required):**
    * Before output, check:
        * Does the text read well?
        * Is the reader persuaded or helped toward their goal (what should they do)?
</language>
</output>

R-I-S-E

R-I-S-E stands for Role – Input – Steps – Expectation:

• Role: what role should Claude take on?
• Input: what information or sources will it receive?
• Steps: what steps should it take to reach the result?
• Expectation: what is the expected result?

This framework suits Claude tasks like:

• creating step-by-step plans
• writing manuals
• documenting processes and working methods
• drawing up instructions and checklists

Example

To write an onboarding manual for a new employee, you could use the framework like this:

<role>
HR operations specialist.
</role>

<input>
Use the attached files:
- [onboarding policy]
- [IT request form]
- [facility information]
</input>

<steps>
<step_1>
Read the attachments and extract the parts relevant to onboarding (HR, IT, facilities).
</step_1>

<step_2>
Group onboarding into phases: before the start date, first day, first week, first month.
</step_2>

<step_3>
Write a short explanation and concrete actions for each phase.
</step_3>

<step_4>
Check that the manual is complete and free of assumptions. Note anything missing as open points.
</step_4>
</steps>

<expectation>
The manual:
- is logically ordered and easy to follow
- is directly usable in practice
- uses clear, professional language
</expectation>

With R-I-S-E you steer mainly on structure, order, and feasibility. You can improve this prompt by adding extra input and instructions:

<role>
HR operations specialist.
</role>

<input>
Use the attached files:
- [onboarding policy]
- [IT request form]
- [facility information]

Audience: new employees.
Goal: a clear onboarding manual, so a new employee knows what to do and what to expect.

If information is missing from the attachments, say so explicitly and do not make assumptions.
</input>

<steps>
<step_1>
Briefly inventory the input needed per phase (what must be arranged before the start date, on the first day, in the first week, and in the first month).
</step_1>

<step_2>
Write the manual in four chapters (before the start date, first day, first week, first month). For each chapter use:
- a short intro (why this phase matters)
- a "What you do" section (concrete actions for the employee)
- a "What to expect" section (what HR, manager, IT, and facilities arrange)
- where relevant: a pointer to the right form or document from the attachments
</step_2>

<step_3>
Add a "Common mistakes and things to watch" section to each chapter, based on the policy and forms.
</step_3>

<step_4>
Check the manual for consistency:
- the same terms for the same things (e.g. system name, forms)
- no contradictions between chapters
- no steps that depend on missing information
</step_4>

<step_5>
Close with a short "Open points" section noting anything not in the attachments but still needed.
</step_5>
</steps>

<expectation>
The manual:
- is complete, logical, and easy to follow
- is immediately usable for new employees
- is concrete enough to follow without extra explanation
- prevents differences in interpretation
</expectation>

<output>
<placement>
[intranet page / onboarding portal / welcome email]
</placement>

<length>
[e.g. 300–500 words]
</length>

<structure>
- Title + short intro
- 4 chapters (before start date / first day / first week / first month)
- Per chapter: "What you do" + "What to expect"
- Close with "Open points"
</structure>

<language level="A2">
These rules apply to the *entire* text below:

* **Language:** Flawless, simple English (US-EN).
* **Level:** Strictly A2 (basic user).
    * Sentences flow a little more than A1, but stay simple.
* **Tone:** Clear and inviting.
  Address the reader as "you" in a [CHOOSE: conversational / formal] register.
* **Sentence structure:**
    * Short sentences (12 words maximum).
    * At most one simple subordinate clause (e.g. with *and*, *but*, or *because*).
    * Prefer the active voice. Avoid the passive voice where possible.
* **Word choice:**
    * Words from everyday life (work, school, family, groceries).
    * Explain words that are not everyday.
* **Form:**
    * **Start each paragraph with the key sentence.**
    * Short paragraphs (3 lines maximum).
    * Use bullet points only for clear lists.

* **Check (required):**
    * Before output, check:
        * Is the text understandable for someone with little language experience?
        * Is it immediately clear what is expected of the reader (what should they do)?
</language>
</output>

D-R-E-A-M

D-R-E-A-M stands for Define – Research – Execute – Analyze – Measure:

• Define: what is the problem or question?
• Research: what information or sources does Claude use to look into it?
• Execute: what solution or approach does it work out?
• Analyze: how does it evaluate the solution?
• Measure: how does it determine whether the solution works?

This framework suits Claude tasks like:

• running analyses
• setting up improvement projects
• carrying out evaluations
• optimizing processes and working methods

Example

To analyze and improve a customer service process, you could use the framework like this:

<define>
Customer service gets many repeat questions about the same topics every day.
</define>

<research>
Use the attached files:
- [overview of customer questions]
- [FAQ or knowledge base]
- [recent support tickets]
</research>

<execute>
Work out a proposal to reduce the number of repeat questions.
</execute>

<analyze>
Assess how well the proposal addresses the main causes of the questions.
</analyze>

<measure>
Describe how we can measure whether the number of repeat questions goes down.
</measure>

With D-R-E-A-M you focus on insight, evidence, and measurable effect. You can improve this prompt by making the problem more concrete and explicitly asking for analysis and measurement points:

<define>
Customer service gets many repeat questions about delivery, returns, and invoicing. This drives up workload and lengthens response times.
</define>

<research>
Use the attached documents as your source:
- [overview of customer questions]
- [FAQ or knowledge base]
- [recent support tickets]

If information is missing from the documents, say so explicitly and do not make assumptions.
</research>

<execute>
Work out an improved approach to reduce repeat questions. Consider:
- better information for customers
- changes to existing FAQs or help texts
- possible process or communication improvements
</execute>

<analyze>
Analyze the proposed approach:
- which causes of repeat questions does it address?
- which questions will likely remain, and why?
- what does this approach ask of customers and the support team?
</analyze>

<measure>
Describe how we can measure the effect of the new approach, for example:
- fewer support tickets per topic
- a shorter average handling time
- fewer recurring questions within the same category
</measure>

Wizard prompts: work out a document together

Frameworks work when you know what you want and can describe it up front. Some work isn't like that: your thinking only takes shape as you go, so you can't hand Claude the full answer at the start.

A wizard prompt is a brief too. What changes is what you're briefing Claude to do: not carry out a task, but work something out with you. Instead of instructing it once, you set it up to interview you: a few questions at a time, waiting for your answer before moving on.

I use these for early product work at Elah. A problem statement I'd struggle to write cold becomes straightforward when Claude walks me through it: what's happening now, who's affected, the root cause, the outcome. The same shape works for any document you'd normally build in stages.

The anatomy of a wizard prompt

Every wizard prompt I use is built from the same seven blocks:

Example: a problem-statement wizard

A problem statement is a good example. You usually carry the rough shape of one in your head. Getting it onto paper is the hard part, and a vague one sends the whole project the wrong way.

Here's the full wizard prompt I use to write one. It runs five steps, and every step uses the same rhythm: explain the concept, ask a few questions, summarize, wait for confirmation.

<role>
**Chief Product Officer (CPO)**, specializing in early-stage product discovery and problem framing for [product type].
</role>

<task>
Your task is to help **me** write a clear, testable **problem statement** for a new [product type] idea.
</task>

<principles>
- Do **not** invent facts, statistics, personas, or market insights.
- Do **not** propose features, concepts, or solutions.
- Avoid buzzwords and solution-oriented language.
- Clearly label assumptions and uncertainty.
- If critical information is missing, ask questions instead of guessing.
- When uncertainty remains, prefer **explicit exploration with me** over leaving placeholders unexamined.
- Use concise, neutral, product-strategy language.
</principles>

<how_to_work>
Guide me **step by step**. Do **not** jump ahead or combine steps. After each step, **wait for my response** before continuing.

Ask **only what is necessary** at each step (maximum **4 questions** per step).

If information is missing but non-critical:
- First, ask whether I want to explore it together.
- If I do, switch into **guided brainstorming mode**:
  - Propose **2–4 plausible options or directions**
  - Clearly label each as an **assumption or hypothesis**
  - Ask me to react, refine, or choose
- Use `[TBD: …]` **only if we explicitly decide** to leave it open.
</how_to_work>

<step_1 goal="Identify the problem (the gap)">
Explain briefly (1–2 sentences) what "identifying the problem" means.

Then ask me questions to capture:
- What I observe happening today
- What *should* be happening instead
- Who is affected (if known)
- Any evidence I have (even anecdotal)

After I respond:
- Summarize what is clear
- If I express uncertainty or respond with "I don't know," propose a small set of plausible directions (clearly labeled as assumptions) and ask me to react

Summarize:
- **What's happening now**
- **What should be happening**
- **Who is affected**
- **Confidence level** (high / medium / low, with why)

Wait for my confirmation before moving to Step 2.
</step_1>

<step_2 goal="Put the problem into context (orientation + impact)">
Explain briefly what "context" and "impact" mean.

Then ask me only what's needed to understand:
- Where and when the problem occurs
- How often it happens or what triggers it
- Why this problem matters (impact on users and/or business)
- Any relevant constraints (environment, device, workflow)

After I respond:
- Summarize what is clear
- If uncertainty remains, switch into guided brainstorming mode and ask me to react

Summarize:
- **Context (where / when)**
- **Impact on users**
- **Impact on business or team (if relevant)**
- **Key uncertainties**

Wait for my confirmation before moving to Step 3.
</step_2>

<step_3 goal="Find the root cause (not the solution)">
Explain briefly the difference between a **symptom** and a **root cause**.

Then guide me through a lightweight "5 Whys":
- Ask "Why does this happen?" one step at a time
- After each answer, label it as:
  - Observation
  - Inference
  - Assumption

If uncertainty blocks progress:
- Pause and propose plausible root-cause directions as hypotheses
- Ask me to react or narrow them

Stop when:
- A plausible root cause is reached, or
- Uncertainty becomes too high to proceed responsibly

Summarize:
- **Primary root cause(s)**
- **Confidence level for each**

Wait for my confirmation before moving to Step 4.
</step_3>

<step_4 goal="Describe the ideal outcome (success, not solutions)">
Explain briefly what an "ideal outcome" is and what it is **not**.

Then help me describe:
- What changes for the user if the problem is solved
- What improves or stops being painful
- How we would know things are better (signals or indicators, even if rough)

If I struggle to articulate outcomes:
- Propose a small number of outcome directions as assumptions
- Ask me to refine or reject them

After I respond, summarize:
- **User outcome**
- **Business or team outcome (optional)**
- **Signals or success indicators**
- **Open questions**

Wait for my confirmation before moving to Step 5.
</step_4>

<step_5 goal="Write the final problem statement">
First, restate the inputs you are using so I can verify them:
- User
- Problem (gap)
- Context
- Root cause insight
- Outcome / why it matters
</step_5>

<output>

<final_problem_statement>
- Maximum **3 sentences**
- Structured as:
  **User → Problem → Insight → Outcome**
- No solution language
- Use `[TBD: …]` only for uncertainties we explicitly chose not to explore
</final_problem_statement>

<final_check>
Briefly explain (1–2 sentences) why this problem statement is:
- Solution-independent
- Grounded in observed context
- Testable through discovery or research
</final_check>
</output>

<stop_condition>
Stop once:
- The final problem statement and final check are delivered, or
- You need critical clarification to proceed.
</stop_condition>

Every block from the anatomy is in there, in the same order as the table above.

When to use one. A wizard prompt takes longer to write and longer to run than a framework. That trade pays off when the document deserves real thought, and not for a quick task a framework handles in seconds.

Share your experience

• Which framework fit the kind of work you do most?
• Did briefing Claude properly change the quality of what you got back?
• Have you tried a wizard prompt for a document you'd normally write alone – a plan, a proposal, a strategy? Where did it help, and where did it get in the way?

Coming up next?

You now know both kinds of prompts and what a wizard prompt is made of. In Part 2, you'll build a Claude Project that writes them for you: describe what you need, and it drafts the prompt. Then you turn those prompts into a reusable library you can pull from for any task.