CPES - Fact Sheet¶
Quick Reference (Preliminary)¶
| Detail | Info |
|---|---|
| Exam Code | CPES |
| Full Name | Claude Prompt Engineering Specialist |
| Provider | Anthropic |
| Duration | 90 minutes (estimate) |
| Questions | 50-60 (estimate) |
| Passing Score | ~720 / 1000 (estimate) |
| Cost | TBD |
| Delivery | Online proctored |
| Validity | 2 years |
Domain Weights (Preliminary)¶
| Domain | Weight | Focus |
|---|---|---|
| 1. Prompt Fundamentals | 18% | Anatomy, clarity |
| 2. System Prompts and Role | 16% | Persona, constraints |
| 3. Chain-of-Thought / Extended Thinking | 16% | Reasoning elicitation |
| 4. XML Tags / Structured Outputs | 14% | Structure |
| 5. Few-Shot / Many-Shot | 14% | Examples |
| 6. Evaluation and Iteration | 12% | Evals, A/B, regression |
| 7. Prompt Caching Patterns | 10% | Cache-aware design |
Anthropic's 10 Prompting Techniques (As Documented)¶
In rough order from highest impact:
- Be clear and direct
- Use examples (multishot)
- Let Claude think (chain of thought)
- Use XML tags
- Give Claude a role (system prompts)
- Prefill Claude's response
- Chain complex prompts
- Long context tips
- Extended thinking tips
- Iterate and evaluate
These map closely to the exam domains. Memorize the list.
Prompt Anatomy¶
A typical Claude prompt has these layers, in order:
- System prompt (persona, constraints, capabilities)
- Tool definitions (if using tools)
- Cached static context (reference docs, few-shot examples)
- Per-request context (retrieved snippets)
- User message with explicit task
Keep static layers stable; vary only the latest layers.
Clarity Principles¶
- Write as if to a thoughtful but new colleague
- State the goal explicitly, not implicitly
- Specify the audience for the output
- Specify the format of the output
- Specify length and tone constraints
- State what NOT to do when relevant
- Avoid ambiguity ("be brief" vs "respond in 2-3 sentences")
System Prompts¶
The system field sets:
- Role / persona
- Background context that applies to every turn
- Capabilities and limitations
- Default behaviors (length, tone, format)
- Constraints (do not reveal X, do not produce Y)
System prompts persist across the entire conversation. User prompts vary.
Role Prompting¶
"You are a senior security engineer reviewing code for vulnerabilities."
Effects:
- Activates relevant vocabulary and behaviors
- Constrains scope
- Helps Claude default to appropriate technical depth
Limits:
- Roles do not override safety; Claude will refuse harmful content regardless of role
- Overly cute personas can degrade quality on technical tasks
- Generic roles ("helpful AI") add little
Chain of Thought (CoT)¶
Three flavors:
- Implicit - "Think step by step." Brief, often sufficient.
- Structured - "First, X. Second, Y. Then, Z."
- Tagged - Use
<thinking>and<answer>XML tags so reasoning and answer can be parsed separately.
Use CoT when:
- The task requires multi-step reasoning
- Quality matters more than latency
- You can verify or extract just the final answer
Skip CoT when:
- The task is single-shot retrieval or classification
- Latency is critical
- Extended thinking is enabled (which serves the same purpose more effectively)
Extended Thinking vs CoT¶
| Aspect | CoT in Prompt | Extended Thinking |
|---|---|---|
| Where | In your prompt | Native API feature |
| Visibility | Visible in response | Returned as opaque thinking blocks |
| Cost | Counts as output | Counts as output (separately reported) |
| Models | All | Models that support thinking |
| Best For | When you want visible reasoning | When you want quality without prompt clutter |
You can combine both, but it is rarely necessary.
XML Tags¶
Claude responds especially well to XML-tagged structure. Common tags:
<instructions>- what to do<context>- background info<examples>- few-shot demonstrations<input>/<document>- source material<output_format>- how to respond<thinking>- reasoning scratchpad<answer>- final response
Pick names that mean something for your domain. Be consistent across prompts.
Structured Outputs¶
Three production patterns:
- Forced tool choice with a schema tool (most reliable)
- JSON output via prefill: start the assistant with
{to force JSON - XML wrapping: ask Claude to put the answer in
<json>...</json>and parse out
For strict schemas, prefer #1.
Prefill¶
You can pre-fill the start of Claude's response by appending an assistant message:
[..., {"role": "assistant", "content": "{"}]
Effects:
- Forces Claude to continue from your prefill
- Useful for JSON outputs (prefill
{) - Useful for skipping pleasantries
- Removes most refusal preambles
Limits:
- Only short prefixes work well
- Prefill content is not generated; you supplied it
Few-Shot Prompting¶
Provide N examples of input/output pairs to demonstrate format and behavior.
Guidelines:
- 2-5 examples is typical; more for harder tasks (many-shot)
- Examples should span the input distribution
- Include edge cases as examples
- Format examples consistently with intended output
- Wrap examples in XML tags for clarity
Many-shot (dozens of examples) can outperform few-shot for nuanced tasks. Cost more in tokens.
Example Selection¶
Bad: 5 nearly identical examples. Wastes tokens, narrows behavior.
Good: 5 examples spanning easy / typical / hard / edge / counter-example.
For dynamic systems: retrieve relevant examples per request from an examples library.
Counter-Examples¶
Showing what NOT to do can be powerful:
<example>
<input>...</input>
<bad_output>This output is wrong because it omits X.</bad_output>
<good_output>This is the correct response.</good_output>
</example>
Use sparingly; overuse can confuse.
Long Context Tips¶
When your prompt includes a long document:
- Place the document before the question
- Use XML tags to delimit the document clearly
- Ask Claude to quote relevant passages before answering
- Place the question at both the top and bottom of the prompt for very long inputs (Claude pays more attention to recent tokens)
- Use prompt caching on stable long contexts
Iteration Loop¶
- Define the task and success criteria
- Build a starter eval dataset (20-50 items)
- Write v1 prompt
- Score v1 against the eval set
- Identify failure modes; categorize them
- Targeted prompt change addressing one failure mode
- Re-score; compare to v1
- If better, ship v2; if not, revert and try another change
- Repeat
Discipline: change one thing at a time. Otherwise you cannot attribute improvements.
Eval Patterns¶
- Unit checks: schema valid, contains expected term, length within range
- LLM-as-judge: Claude grades against a rubric
- Pairwise: judge picks between two outputs
- Human spot checks for calibration
Prompt Caching Design¶
To make prompts cache-friendly:
- Place all static content first
- Put
cache_controlat the end of stable regions - Avoid templating in dynamic values inside cached regions
- Order: system prompt -> tools -> reference docs -> examples -> dynamic context -> user message
- Verify with
cache_creation_input_tokensandcache_read_input_tokens
High-Yield Tips¶
- XML tags help Claude parse structure
- Be explicit, not clever
- Examples beat instructions for format
- Prefill solves many output-format problems
- Extended thinking beats CoT for hard reasoning
- Cache the static prefix
- Iterate with evals, not vibes
- Counter-examples are powerful but easy to overdo
- Forced tool choice is the most reliable structured output
- Long contexts: question at top AND bottom
Common Traps¶
- Putting dynamic values inside the cached prefix
- Asking Claude to "be brief" instead of specifying tokens or sentences
- Stacking 20 examples when 4 would do
- Using prompts to enforce safety policies (defense in depth: prompt + classifier)
- Forgetting that role prompting is not a security control
- Long prompts with the question buried in the middle
- Iterating without a baseline measurement
- Calibrating LLM judges against zero human labels
- Confusing extended thinking (native) with CoT (prompt technique)
- Thinking prompt caching is automatic - it requires explicit
cache_control