Prompt Engineering

What this domain covers

Writing effective prompts, advanced techniques like chaining and Plan Mode, and designing for structured, evaluable output.

4.1Writing Effective Prompts

Clarity and specificity beat cleverness. A prompt that states the exact output format, the constraints, and one or two concrete examples of what a good answer looks like will consistently outperform a vaguer prompt with more adjectives.

Positive examples show the target; negative examples — showing a plausible but wrong answer and why it's wrong — are often what actually close the gap on a model that's been getting close-but-not-quite results.

System prompts set durable context and role framing that should hold for the whole interaction; user turns carry the specific task at hand. Conflating the two — burying durable rules inside a one-off user message — is a common design mistake that makes behavior inconsistent across turns.

Key points

Specific format + constraints + example beats a vaguer, more verbose prompt.
Negative examples (wrong answer + why) often close gaps that positive examples alone don't.
System prompt = durable role/context; user turn = the specific task.

Full breakdown & examples → 4.1 Writing Effective Prompts

4.2Advanced Prompt Techniques

Chain-of-thought / step-by-step prompting asks the model to reason before answering, which measurably improves accuracy on multi-step problems by giving the model room to catch its own intermediate mistakes before committing to a final answer.

Prompt chaining breaks one complex task into a sequence of smaller prompts, where each step's output feeds the next — trading a single hard-to-verify generation for several easier-to-verify ones, at the cost of extra latency and orchestration complexity.

In Claude Code specifically, Plan Mode has Claude propose an approach and get it approved before touching any files, versus direct execution, which starts making changes immediately. Plan Mode trades speed for a checkpoint on higher-risk or higher-ambiguity changes — the same trade-off Domain 1 describes for agentic checkpoints generally.

Key points

Chain-of-thought gives the model room to self-correct mid-reasoning before finalizing an answer.
Prompt chaining trades one hard-to-verify step for several smaller, easier-to-verify ones.
Plan Mode = review-before-acting checkpoint; direct execution = immediate action. Same trade-off as Domain 1 checkpoints.

Full breakdown & examples → 4.2 Advanced Prompt Techniques

4.3Structured Output and Evaluations

Getting reliable machine-consumable output (JSON, a fixed schema) means specifying the exact shape wanted, showing an example of that shape, and being explicit about what happens with missing or uncertain fields — ambiguity here shows up downstream as a parsing failure, not a conversational misunderstanding.

An evaluation set is a fixed collection of representative inputs with known-good outputs (or a grading rubric), used to measure whether a prompt change actually improved things or just felt better on the one example you tried.

Automated eval pipelines apply a grading rubric — sometimes another Claude call scoring the output — consistently across the whole set, which is what makes it possible to detect a regression before it reaches production rather than after a user reports it.

Key points

Structured output reliability comes from an explicit schema + example + defined behavior for missing/uncertain fields.
An eval set is what turns 'this prompt feels better' into a measurable, repeatable comparison.
Automated grading rubrics (sometimes model-graded) make eval pipelines scalable and catch regressions early.

Full breakdown & examples → 4.3 Structured Output and Evaluations

Check yourself

1.You want Claude Code to review a risky refactor's approach before it edits any files. Which mode do you use?

Show answer

Plan Mode — it has Claude propose the approach and get explicit approval before making any changes, rather than executing directly.

2.A prompt produces JSON that's usually well-formed but occasionally omits a required field with no explanation. What's the most direct fix?

Show answer

Make the schema and the expected behavior for missing/uncertain fields explicit in the prompt (e.g., a required field with a defined fallback or null-handling rule), rather than leaving that case unstated.

3.Why use an evaluation set instead of just eyeballing a couple of example outputs when iterating on a prompt?

Show answer

A single example can look better by chance or because it happens to match your mental model; an eval set with representative inputs and a rubric measures whether a change actually improves performance across cases, and can catch regressions.

← Claude CodeAll DomainsContext Management →

Claude Certified Architect — Study NotesDWG 04