Hands-On: Refactoring Prompts with XML Tags

This lesson is about building muscle memory. You've learned the theory — now you'll apply it across four real-world domains where XML tags have a significant impact on output quality. For each scenario, you'll see an unstructured "before" prompt, understand why it falls short, and then refactor it yourself.

How to Use This Lesson

Read the "before" prompt and the explanation of its weaknesses. Then complete the exercise by rewriting the prompt using the XML patterns from this module. Use the free-form playground at the end to experiment further.

---

Scenario 1: Customer Support Triage

The "before" prompt:

You are a customer support agent for a cloud storage company. A customer named James has been with us for 3 years and is on the Business plan paying $299/month. He sent this message: "I just realized that 3 months of our backup data appears to be missing from the dashboard. This is critical for our compliance audit next week." Assess the urgency, determine if this needs escalation, write a response to James, and note any compliance risks.

Why it falls short:

Everything runs together in one dense paragraph. Claude receives the agent persona, the customer background, the customer message, and the four-part task as a single undifferentiated block. This creates several problems:

• The task requirements (four distinct actions) are buried in the middle
• Claude may deprioritize compliance risk assessment since it's mentioned last
• The customer message isn't clearly isolated from the surrounding instructions
• The prompt is hard to maintain — adding another instruction requires rewriting a sentence

Refactored version to study:

<context>
  Role: Customer support agent, CloudVault (cloud storage and backup service)
  Customer: James, 3-year customer, Business plan ($299/month)
  Current status: No open support tickets
</context>

<customer_message>
  "I just realized that 3 months of our backup data appears to be missing from the dashboard.
  This is critical for our compliance audit next week."
</customer_message>

<instructions>
  Complete all four of the following tasks:

  1. **Urgency assessment**: Rate urgency P1/P2/P3 with one-sentence justification
  2. **Escalation decision**: Should this go to Tier-2 or account management? Why?
  3. **Customer response**: Draft a reply to James (professional tone, acknowledge urgency, set expectations)
  4. **Compliance risk note**: Flag any potential compliance or legal exposure for internal review
</instructions>

Now you try it with a different scenario:

---

Scenario 2: Code Review

The "before" prompt:

Please review this Python function. Check for bugs, security issues, and performance problems. Also tell me if the naming is good and if it follows best practices. Be thorough. Here's the code: def get_user(user_id): result = db.query(f"SELECT * FROM users WHERE id={user_id}"); return result[0] if result else None

Why it falls short:

The code is embedded inline in the instructions, making it hard to parse. "Be thorough" is vague — thorough about what, and in what order? The review criteria are a comma-separated list rather than a structured priority order, so Claude might weight them arbitrarily.

Refactored version to study:

<instructions>
  Review the provided Python function and evaluate it across the following criteria, in this order:

  1. **Security**: SQL injection, authentication issues, data exposure
  2. **Correctness**: Bugs, edge cases, error handling gaps
  3. **Performance**: Query efficiency, unnecessary operations, indexing implications
  4. **Code quality**: Naming clarity, PEP 8 compliance, documentation

  For each issue found: state the category, describe the problem, and provide a corrected code snippet.
  For criteria with no issues, state "No issues found."
</instructions>

<code language="python">
def get_user(user_id):
    result = db.query(f"SELECT * FROM users WHERE id={user_id}")
    return result[0] if result else None
</code>

Now practice with a more complex code snippet:

---

Scenario 3: Content Analysis

The "before" prompt:

Read this article and tell me the main arguments, what evidence is used, whether the logic holds up, and what the article is missing. Article: [paste 2000-word article here]

Why it falls short:

Four distinct analytical tasks are listed as a comma-separated sentence. The article content will flow directly into the instruction text with no clear boundary. There's no specification of output length, format, or priority. "Whether the logic holds up" is undefined — by what standard?

Refactored version to study:

<context>
  Purpose: Editorial review for publication on a technology policy blog.
  Audience: Technically literate, skeptical readers who expect rigorous sourcing.
</context>

<article>
  [article text here]
</article>

<instructions>
  Analyze the article across four dimensions:

  **1. Main Arguments** (2-3 sentences)
  What is the article's central thesis? What are the 2-3 supporting claims?

  **2. Evidence Assessment**
  For each major claim: what evidence is provided (data, expert opinion, anecdote, none)?
  Rate evidence quality: Strong / Adequate / Weak / Unsupported

  **3. Logical Coherence**
  Identify any logical fallacies, unsupported leaps, or contradictions between sections.
  Rate overall logical coherence: Sound / Minor Issues / Significant Problems

  **4. Coverage Gaps**
  What important perspectives, counterarguments, or evidence does the article fail to address?
  List 2-4 specific gaps with a brief explanation of why each matters.
</instructions>

Scenario 4: Free Experimentation

Now put everything together. Use this playground to experiment with any prompt scenario you're working on — or try creating a new XML-structured prompt from scratch.

Some prompts to try if you don't have your own:

Option A: Meeting notes to action items Structure a prompt that takes raw meeting notes as <input> and produces structured action items with owner, deadline, and priority.

Option B: Resume screening Build a multi-document prompt using <documents> that compares a job description with a candidate's resume and produces a structured match analysis.

Option C: Sentiment + topics from social media Design a prompt that takes a batch of customer comments and produces XML-structured output with sentiment and topic classification for each.

Patterns to Remember

Across all four scenarios, the same structural decisions come up repeatedly. Here's a quick reference:

Situation	Pattern to use
Multi-part tasks	Number them in <instructions>
Content to analyze	Isolate in <input>, <article>, <code>, or <document>
Customer or user info	Keep in <context>, not inside instructions
Multiple source docs	Use <documents><document index="N"> pattern
Batch items	Use numbered or id-attributed child tags inside a container
Output schema	Show the exact structure with placeholders in <instructions>

The single most impactful habit: never let the content you're asking Claude to process run together with the instructions. Always isolate input content in its own tag. This one change — <input>...</input> around user-provided content — prevents more prompt failures than any other single technique.

Key Takeaways

• The content isolation principle is the highest-value XML habit: input content always gets its own tag, separate from instructions
• For multi-part tasks, number the sub-tasks explicitly inside <instructions> — Claude addresses each one when they're enumerated
• Use <context> for background that stays stable across requests (customer info, role definition, constraints)
• For batch analysis, use id-attributed child tags inside a container to let Claude reference individual items clearly
• The same structural logic applies whether you're doing support triage, code review, content analysis, or data extraction — the tags change, the pattern doesn't