Before a single prompting trick, get this straight: the model is a power tool, not a pilot. It amplifies your thinking, it doesn't replace it. People who master AI keep their judgment, their voice, and their skills sharp while using it. People who lose themselves hand all three over and slowly forget how to do the work. This whole course assumes you stay in charge.

The same tool, three arenas

The skill is identical; only the stakes and judgment change. Wherever you use it, the line is the same: let it do the lifting, keep the thinking.

Five habits that keep you in charge

1. Bring intent. Know what you want before you ask. A tool serves a goal; it can't supply one.
2. Verify before you trust. Fluent isn't the same as correct. Check facts, numbers, and claims, especially when it matters.
3. Stay the editor. Make the final call on wording, tone, and judgment. Never ship anything you wouldn't put your name on.
4. Keep your own skills warm. Use it to do more, not to forget how. Now and then, do the thing yourself.
5. Protect your context. Don't pour private or sensitive data in for convenience (more in the Safety module).

Know how it fails: it wants to please you

Understand this before you trust a single answer. These models are trained on human ratings, so they learn to give replies people like, not replies that are true. That creates two failure modes you have to actively guard against.

The fix is to stop asking it to agree with you and start making it work against you:

• Make it argue the other side. "Give me the strongest case against this," not just "what do you think?"
• Force the uncertainty into the open. "Flag what you're unsure about and what you're assuming."
• Ask what would break it. "What would make this wrong? What am I not seeing?"
• Demand checkable sources and verify anything that matters. Never treat "you're absolutely right" as evidence that you are.

For this conversation, do not flatter me or simply agree. Your job is to pressure-test my thinking.

When I share a plan, decision, or claim:
1. Steelman the strongest case FOR it, then the strongest case AGAINST it.
2. Name the assumptions I haven't checked and the one thing most likely to make me wrong.
3. Flag anything you are uncertain about. Do not invent sources or numbers; if you don't know, say so.

Be direct and specific. I would rather be corrected now than comfortable and wrong.

Sources: Giskard, sycophancy in LLMs; Duke University Libraries, on persistent hallucination.

I want to use you as a tool that amplifies my thinking without making me dependent on it.

Here is what I do (work / study / personal): [describe in 2-3 sentences].

1. Ask me 5 sharp questions to find where AI would genuinely help me versus where I should keep doing the thinking myself.
2. Then give me a short, honest "use it / keep it human" guide tailored to me.
Be direct. Don't flatter me.

Before any technique, internalise the structure of a good instruction. Almost every weak prompt is missing one of five parts.

The five components

Principles that power each component

1 · Be clear and direct, specificity beats cleverness

2 · Give the why, not just the what

3 · Say what TO do, not what NOT to do

Positive instructions are followed more reliably than negative ones. "Write in flowing prose paragraphs" beats "don't use bullet points."

4 · Mind placement, the "lost in the middle" effect

Long-context models often perform worse when critical information is buried in the middle of a long context. Place key instructions and evidence near the start or end, and for long documents, putting the source material first and your question last tends to help. Treat the size of the effect as model-dependent and verify on your target model.

Few-shot, done right

Examples are the most powerful, and most misused, lever. Make them Relevant, Diverse (cover edge cases so the model doesn't latch onto an accidental pattern), and Structured (wrap each in tags). Three to five is a common sweet spot for non-reasoning models; on reasoning models, prefer fewer (the reasoning-model module).

# developer note: clean, tagged few-shot examples
<examples>
  <example>
    <input>The checkout button is broken on mobile.</input>
    <output>{"type":"bug", "area":"checkout", "severity":"high"}</output>
  </example>
  <example>
    <input>Could you add dark mode?</input>
    <output>{"type":"feature_request", "area":"ui", "severity":"low"}</output>
  </example>
</examples>

Classify this ticket the same way: "{{ticket}}"

Delimiters & structure

When a prompt mixes instructions, context, and data, separate them with explicit boundaries. XML tags (<instructions>, <context>, <input>) are especially well-handled by Claude; markdown headers and triple backticks work across providers. Use consistent, descriptive tag names and nest for hierarchy.

Output control, three reliable levers

• Tell it the shape you want, not the shape to avoid.
• Use a format indicator: Write the answer inside <summary> tags.
• Prompt formatting can influence output formatting; to get cleaner prose, reduce unnecessary markdown in your prompt and specify the desired output style explicitly. For machine consumption, prefer a provider's structured-output / JSON-schema feature over asking in prose.

Templates, the bridge to production

# reusable template
You are a {{role}}. Your task: {{task}}.
Context: {{context}}
Constraints: {{constraints}}
Return the result as {{format}}.

Worked examples across domains

Prompting transfers across fields. Same skeleton, different domain, including one multilingual and one fairness-sensitive case.

We teach this before the historical techniques on purpose. Reasoning models do internal thinking before answering, so the modern default is the baseline you should reach for first.

The new knob: effort / thinking controls

Manual reasoning scaffolds can be supplemented by a dial. Learn the knob per provider, if a model overthinks, lower the setting rather than rewriting the prompt.

# Anthropic, adaptive thinking with the effort dial
client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # low|medium|high|xhigh|max
    messages=[{"role": "user", "content": "..."}],
)

These techniques shaped the field and still matter, both because you'll meet them in older systems and because the ideas inform good prompts. Read them as historical patterns with current limits, not defaults. Test each against a simpler prompt before adopting it.

RAG-aware prompting (still high-value)

Grounding answers in retrieved documents remains one of the most reliable techniques. The prompt matters as much as the retrieval:

• Wrap each document in tagged structure with source metadata.
• Ask the model to extract the relevant quotes first, then answer from those quotes, this cuts through noise.
• Demand inline citations; treat provenance as a requirement.

<documents>
  <document index="1">
    <source>policy_v4.pdf</source>
    <content>{{chunk}}</content>
  </document>
</documents>

# 1) extract quotes  2) answer ONLY from them  3) cite  4) admit gaps
First extract the exact quotes relevant to the question into <quotes> tags.
Then answer using only those quotes, citing each as [source].
If the documents don't contain the answer, say so.

1. Vagueness. "Write something about marketing." The single biggest failure mode.

2. Over-prompting. Stuffing every rule in up front, so the model carries the load even on trivial requests. Worse on reasoning models.

3. Sloppy few-shot. "Close enough" examples, where the model copies your format flaws exactly.

4. Vague verification. "Double-check your work" with no criteria yields "looks good." Specify what to check against.

5. Negative framing. Lists of "don'ts" are followed less reliably than positive instructions.

6. Ignoring token cost. Bloated context is expensive and dilutes attention. Trim aggressively.

7. Reflexive CoT on reasoners. Adding hand-built reasoning steps and heavy few-shot to models that already reason.

8. Stale emphatic language. Leftover "CRITICAL / MUST" can cause over-triggering on frontier models.

9. One-shot perfectionism. Treating prompting as writing one perfect string instead of an iterative loop.

A systematic failure-diagnosis flow

The difference between dabbling and mastery: you treat prompting as an engineering loop, not authoring. Define success before you write the prompt.

An analytic rubric for grading prompts

Use this to grade your own and peers' prompts. Analytic (not holistic) so the fix is obvious.

Key practices

• Living test suite: every production failure becomes a permanent test case.
• Version-control prompts like code, with dev/staging/prod and rollback.
• LLM-as-judge for scalable scoring, but validate the judge against human labels first.
• Isolate variables when debugging, change one thing at a time, fix inputs, and on reasoning models try removing scaffolding before adding it.

Write to the intent, role, task, constraints, format, then adapt the encoding per provider. Always verify against current official docs, since these details move.