Lesson 1 of 5 in Prompt Engineering & Structured Output

3.1 · Prompt fundamentals

Prompt engineering is the highest-leverage skill on the exam and in production. This lesson covers the four-part prompt skeleton (role, task, input, output format), the system-vs-user distinction, structural devices like XML tags, and the categorical-criteria pattern that beats vague 'be careful' instructions.

Clarity beats cleverness

State the task, the input, the output format, and the constraints. Every prompt has these four pieces whether you write them or not. Making them explicit shrinks the surface area for misinterpretation.

System vs user roles

System prompt: persistent role, rules, and reference material the model needs on every turn. User message: the specific task and input for this turn. Putting everything in one place is fine for prototypes; splitting is standard for production.

system: 'You are a claims adjuster. Follow policy X.'
user: 'Claim #1234: driver hit a deer. Recommend action.'

XML tags as structural glue

Claude is trained to recognize XML tags as delimiters. Use them to partition long prompts unambiguously: <instructions>, <example>, <document>, <output_format>. They work better than markdown headers or triple newlines because they're unambiguous.

# Ambiguous — where does the document end?
Extract the total from this document:
Invoice #4482 from Acme Corp, total $1,240.50, ...
Return JSON with a 'total' field.

# Unambiguous — clean partitions
<instructions>
  Extract the invoice total. Return JSON.
</instructions>

<document>
  Invoice #4482 from Acme Corp, total $1,240.50, ...
</document>

<output_format>
  {"total": <number>, "currency": <ISO code>}
</output_format>

Positive over negative

Tell Claude what to do, not what to avoid. 'Respond in declarative sentences' beats 'do not hedge.' Negative instructions require the model to hold the negation in mind while composing; positive ones just describe the target.

Good to know — A prompt full of 'do not' is a smell. Try to rewrite each as a 'do'.

Takeaways

  • Task, input, output format, constraints — every prompt has these
  • System = role/rules; user = task/input
  • XML tags partition long prompts unambiguously
  • Positive instructions outperform negative

Exam traps

Confusing 'user-level' with 'team-level' configuration
User-level (~/.claude/CLAUDE.md) lives only on your machine — new teammates don't see it. Team standards go in project-level (./CLAUDE.md, checked into git).
Skipping plan mode for high-risk multi-file changes
Plan mode is the safer default for architectural changes, cross-cutting refactors, or destructive operations. Direct execution is for single-file, clear-intent tasks.
Assuming .claudeignore blocks writes
.claudeignore controls what Claude READS. To block writes, use a PreToolUse hook.

Practice scenario

A new team member joins a repo and Claude Code doesn't seem to know the project's testing conventions. Investigation shows the previous maintainer had a detailed testing rule in their own ~/.claude/CLAUDE.md. What's the fix?

Next →