Workshop #2 of the AI Fridays series. Workshop #1 covered what Claude is. Today is how to talk to it so it gives you something useful the first time.
Most prompts written are too vague, too short, missing context, or doing three things at once. The output is bad, and people blame the model. The model is usually fine. The prompt is the problem.
By the end you'll be able to:
Prompt engineering is the practice of writing inputs to a language model so it reliably gives you outputs you can use. Not magic incantations — a small set of techniques that reduce how often the model misunderstands, hallucinates, or produces something useless.
This workshop covers six principles, one reusable skeleton, and three techniques in particular: meta prompting (asking the model to write or improve a prompt for you), prompt chaining (breaking a task into separate calls), and self-critique (a reviewer pass that catches what the producer missed). Anthropic also publishes a free interactive tutorial if you want a deeper version.
Five common patterns that produce weak output. Each one maps directly to a missing or weak block in the skeleton.
"Improve this." "Make it better." "Optimise."
The model has no idea what dimension to improve along — clarity? length? tone? structure? accuracy? It picks one and you're unhappy with the result.
Fix: name the specific change. "Shorten to 120 words." "Rewrite in a neutral tone, drop the marketing adjectives." "Add a section on pricing." That's a real task.
Skeleton block: <task> + <requirements>"Write a reply to this customer." [no customer message attached]
You know what the customer said. The model doesn't. It will invent something plausible-sounding and you'll send it and look silly.
Fix: paste the customer's message inline. Paste the doc, the chunk of code, the ticket history, the numbers — whatever the model needs to do the task. The model can't read your screen.
Skeleton block: <context>"Summarise this report, find the gaps in our pricing strategy, and write a follow-up email to the customer."
Each of those is a real task. Together they're a mess. The model does each one badly, the email is generic because the gap analysis was shallow because the summary was rushed.
Fix: one task per prompt. Run them as three separate prompts and feed the output of each into the next.
Skeleton block: <task>"Write a LinkedIn post about our new product."
The model has no boundaries. It produces 600 words of corporate-LinkedIn slop with three emojis, two "in today's fast-paced world," and a call to action you'd never write yourself.
Fix: set explicit bounds. "Under 120 words. Plain prose, first person, conversational, neutral factual tone."
Skeleton block: <constraints>"Explain this code." You get five paragraphs. Is that good? Is it wrong? You can't tell.
Without a definition of "done," you can't tell whether the answer is acceptable, and you'll burn time re-prompting until it feels right.
Fix: define checks the answer should pass. "The explanation should mention the auth flow, the error handling, and why we use a queue here. If any of those is missing, flag it." Now you have a checklist.
Skeleton block: <success_criteria>Across the chapters of Anthropic's Interactive Prompt Engineering Tutorial and the Prompting best practices doc, six principles recur. A good prompt:
| Principle | What it means in practice |
|---|---|
| Is clear and direct | If a colleague with minimal context couldn't follow your prompt, Claude can't either. Specific verbs beat vague ones; concrete numbers beat hand-waves. Example: Shorten the email below to 120 words and remove all marketing adjectives. — not improve this. |
| Assigns a role | Even one sentence about who the model is acting as sharpens tone and focus. Example: <role>You are an Acme support agent with five years of experience explaining battery test results to non-technical buyers.</role> |
| Separates data from instructions | XML tags around pasted documents, examples, and inputs prevent Claude from confusing material it's analysing with what it's been told to do. Example: <context>...the customer's email goes here...</context> |
| Specifies the output shape | State the format (table? prose? bullet list? word count?) explicitly. The docs add a key point: tell Claude what to do, not what not to do — "use plain prose" beats "don't use markdown." Example: <output_format>Markdown table. Three columns: name, price, recommendation. Under 200 words.</output_format> |
| Shows, not just tells | A few labelled examples ("here's an input, here's the right output") beat any amount of abstract instruction. Anthropic's sweet spot is 3–5 examples, relevant and diverse. Example: <example><input>Battery at 78% SOH</input><output>Caution band — flag for dealer review.</output></example> |
| Has guardrails against hallucination | For factual or numerical work, instruct the model to say "I don't know" rather than guess, and to quote from supplied documents before drawing conclusions. Example: If you're not sure of a number, say "I don't know" — don't estimate. Quote the relevant line from the doc before drawing any conclusion from it. |
This is the Prompt Standard. It's the canonical skeleton we use for any non-trivial prompt — emails, code, analysis, customer messages, internal docs, anything. The source of truth lives in the reprompt git repo at reference/standard.md; the Notion page is a published copy.
Copy the block below. Fill in every section. Delete blocks only if they truly don't apply. Then paste into Claude (or ChatGPT, or Gemini — this isn't Claude-specific).
Don't want to fill it in yourself? Paste the skeleton into Claude and say "interview me one block at a time and assemble the filled-in prompt."
<role>
You are a [seniority + specialty]. [One sentence on perspective or bias.]
</role>
<task>
[One sentence. What is the deliverable?]
</task>
<context>
- [Background fact 1 — what system, product, or situation this is about]
- [Background fact 2 — constraints already in place]
- [Any relevant data, doc snippets, or links pasted inline]
</context>
<instructions>
[Optional. Use when analysis order matters.]
1. [First step — e.g. "Read the form carefully and list every checked box before looking at anything else."]
2. [Second step — e.g. "Then look at the sketch with the form context already in mind."]
3. [Third step — ...]
</instructions>
<requirements>
- [Must-have 1]
- [Must-have 2]
- [Must-have 3]
</requirements>
<constraints>
- [What NOT to do]
- [Things to preserve / not break]
- [Tone, length, format limits]
</constraints>
<examples>
[Optional but powerful. Use when you have labeled cases that show the pattern.]
<example>
<input>[sample input]</input>
<output>[the right answer for that input]</output>
</example>
<example>
<input>[a tricky edge case]</input>
<output>[how to handle it]</output>
</example>
</examples>
<grounding_rules>
- If you don't know, say "I don't know" rather than guessing.
- Think step-by-step before answering.
- Only assert facts you are confident in. Mark uncertain claims as "likely" or "uncertain".
- When using a document I provided, quote the relevant passage before drawing a conclusion from it.
</grounding_rules>
<output_format>
[Exact shape of the answer. Headings? Bullet list? Code block? Word count? Sections?]
</output_format>
<success_criteria>
- [Test 1: how I will know the answer is good]
- [Test 2: ...]
- [Test 3: ...]
</success_criteria>XML tags let Claude parse each section unambiguously, so order matters less than getting each block right. One exception, per Anthropic: long prompts (20k+ tokens) — put pasted data near the top and the task near the end (up to 30% quality lift).
Every example below is from the same scenario: a customer emails support saying their Acme tester won't start — car isn't running, can't find the OBD port, no status LEDs.
| Block | Why it matters |
|---|---|
<role> |
Frames the model's perspective. "Senior backend engineer" produces different answers than "junior intern". Be specific about seniority and specialty. Example: <role>You are a senior Acme support agent who's seen this scenario many times.</role> |
<task> |
One sentence keeps you honest. If you can't write it in one sentence, you don't know what you want. Anthropic's golden rule: show your prompt to a colleague with minimal context — if they'd be confused, Claude will be too. Example: <task>Draft a reply to the customer below.</task> |
<context> |
Replaces guessing with facts. Paste the relevant doc or data inline rather than expecting the model to know. The model can't read your screen, your Notion, your Slack. Example: <context> - Acme's tester is OBD-powered — no battery. - No status LEDs = no power = OBD-II connection issue. - Customer's email: "Tried to test today — car isn't running, couldn't find the OBD port, no LEDs. Is it broken?" </context> |
<instructions> |
Optional. Step-by-step analysis order. Use when the order in which the model processes information matters (e.g., "read the form before looking at the sketch"). For pure generation tasks, you can usually skip this. Example: useful here because the customer raised three issues at once — the model should diagnose before drafting. <instructions> 1. Read the customer's email and list every distinct issue they raised. 2. For each issue, identify the most likely root cause from the <context> block. 3. Draft the reply addressing the issues in order: quickest fixes first, escalation path last. </instructions> |
<requirements> |
Must-haves. The output is wrong without these. Example: <requirements> - Acknowledge the frustration without conceding the device is broken. - Address each of the three issues with a concrete next step. - If the customer named a make/model, look up the OBD-port location and cite the source URL. - Give an escalation path if the checks fail. </requirements> |
<constraints> |
Bounds and limits — tone, length, format. Frame positively where you can ("use plain prose" beats "don't use markdown"). Outright don'ts only when there's no clean positive form. Example: <constraints> - Under 200 words. - Neutral, factual tone. - Don't blame the customer. - Don't promise a replacement before the checks. </constraints> |
<examples> |
Optional but powerful. 3–5 labelled input/output pairs reliably steer format and tone. You write this block yourself — the cases come from your work. Example: not used here, but would look like: <example><input>previous support email</input><output>the reply we sent and were happy with</output></example> |
<grounding_rules> |
Anti-hallucination. Paste this block as-is into every prompt that touches facts, numbers, or customer claims. Example: <grounding_rules> - If you can't confirm the OBD location for the specific model from a real source, don't guess — ask for a photo of the area under the dashboard. - For anything else you're unsure of, leave a [placeholder] for me to fill in. </grounding_rules> |
<output_format> |
Shape of the answer. Without this, you'll re-prompt three times to get the format you wanted. Example: <output_format> Subject line on the first line, body below with a short numbered list for the three checks. Source URL on its own line at the bottom if the OBD location was looked up. No commentary around it. </output_format> |
<success_criteria> |
Forces you to define "done" before the model answers. Also lets you self-check the output instead of vibing on it. Example: <success_criteria> - The customer can act on the email without replying back for clarification. - If the three checks still fail, what to do next is obvious. </success_criteria> |
Real example: translating page 1 of Acme's Battery Warranty Basic T&Cs into French, Turkish, and German. The prompt we'd naturally type, versus what reprompt rewrote it into.
The complete four-step chain — naive prompt → structured prompt → reviewer agent → refined output — lives in the translation demo. Open it alongside this page to follow the live run.
Translate the first page of this terms and conditions document into French, Turkish, and German. --- Terms and Conditions Acme Battery Warranty Basic 1 General Provisions 1.1 Scope of Application These Terms and Conditions govern the Battery Warranty Basic provided by Acme GmbH, Musterstrasse 1, 1010 Vienna, Austria (hereinafter, "Acme"). The Battery Warranty Basic applies to Eligible Vehicles as defined herein. Warranty holder is the Owner of the Vehicle. 1.2 Legal Nature of the Warranty The Battery Warranty Basic is a voluntary commercial guarantee provided by Acme and does not affect any statutory warranty rights ... [truncated]
<role>
You are a legal translator with experience translating commercial warranty
terms between European languages, working for Acme, an Austrian battery
diagnostics company.
</role>
<task>
Translate the first page of Acme's Battery Warranty Basic Terms &
Conditions (text in <source>) into French, Turkish, and German, preserving
the legal meaning exactly.
</task>
<context>
- Document: Acme Battery Warranty Basic T&Cs, draft dated 2026-04-17.
- Audience: vehicle owners and partner dealerships in France, Turkey, and
Germany/Austria.
- Governing law: Austrian civil law. Translations must not alter the legal
effect of any clause.
</context>
<source>
Terms and Conditions
Acme Battery Warranty Basic
1 General Provisions
1.1 Scope of Application
[full first page pasted here]
</source>
<requirements>
- Produce three full translations: French, Turkish, German — in that order.
- Mirror the source's section numbering and headings exactly.
- "Battery Warranty Basic" is a fixed product name — keep it in English in
all three translations.
- "Acme" stays untranslated.
- Keep the Austrian company address ("Musterstrasse 1, 1010 Vienna, Austria") in its original German form in all three
translations.
- Use formal legal register in each language: vous in French, Sie in
German, siz in Turkish.
- Capitalised defined terms in the source ("Eligible Vehicle", "Warranty
Period", "SoH Threshold", "Owner", "Partner") are defined elsewhere —
keep them capitalised and translate consistently within each language.
</requirements>
<constraints>
- Translate faithfully. Do not paraphrase, summarise, simplify, or
"improve" the source.
- Do not add or omit legal content.
- Output the translations only — no preamble, no commentary.
</constraints>
<grounding_rules>
- If a term is genuinely ambiguous or you're uncertain how to render it in
a given language, mark it inline as [TRANSLATOR NOTE: ...] rather than
guessing.
- For Austrian-law concepts with no direct equivalent in French or Turkish
law, keep the German legal term in parentheses after the translation.
</grounding_rules>
<output_format>
Three top-level sections, in this order:
# Français
[full French translation, mirroring source structure]
# Türkçe
[full Turkish translation, mirroring source structure]
# Deutsch
[full German translation, mirroring source structure]
</output_format>
<success_criteria>
- A native speaker of each target language can read their version and
understand the warranty terms without consulting the source.
- A lawyer comparing source and translation finds no change in legal
meaning.
- Defined terms ("Eligible Vehicle", "Warranty Period", etc.) render
consistently across every occurrence within each language.
- "Battery Warranty Basic" and "Acme" appear unchanged in all three
translations.
</success_criteria>
The naive prompt isn't wrong — it produces serviceable rough translations. But it's silent on every choice that matters: how to handle "Battery Warranty Basic", "Acme", the Austrian address, register, defined terms, concepts with no equivalent in target law. The reprompt version makes those decisions upfront, so you don't catch them three review passes later. That's the game: write down what the model needs, instead of hoping it guesses.
When a prompt produces a result you're happy with, save it somewhere — Notion page, snippets folder, anywhere. Your second "compare two vendors" prompt should take 30 seconds, not 30 minutes.
If you reach for the same prompt over and over, ask Claude to turn it into a skill. No code required:
I use this prompt all the time. Turn it into a skill called "vendor-comparison" that auto-triggers whenever I ask Claude to compare tools or vendors.
[paste your prompt here]Claude scaffolds the skill file, writes the description, sets the trigger. From then on the prompt fires automatically when the situation matches.
reprompt auto-triggers when you write a prompt to Claude. It checks the prompt against the standard and, if anything's weak, shows you what's off and offers a rewrite. Strong prompts pass through unchanged.
For anything where the output matters (legal text, customer-facing copy, anything with numbers you'll quote externally), one prompt isn't enough. The pattern: chained prompts.
Two notes:
The Friday slot hasn't been working. The drop-in is moving to a new day — same format (open office hour, no agenda, lurking welcome), new time.
Reply in #ai-office-hours with the day and time that would get you to show up. I'll go with the most-voted slot and update the calendar invites next week.
To be announced in #ai-office-hours. The current shortlist of topics: Cowork in practice (the tool from workshop #1), connectors and what's safe to wire up to our data, building your own internal skills. If you have a strong preference, post in the Slack channel.
DM Dogus, or post in #ai-office-hours on Slack.
Notes, recaps, the Prompt Standard, the Claude Code setup guide — all in Notion under General Teamspace → KnowHow → the internal AI hub.
Easier to copy from here than from the formatted block in Part 2.
<role>
You are a [seniority + specialty]. [One sentence on perspective or bias.]
</role>
<task>
[One sentence. What is the deliverable?]
</task>
<context>
- [Background fact 1]
- [Background fact 2]
- [Relevant data, doc snippets, or links pasted inline]
</context>
<instructions>
[Optional. Use when analysis order matters.]
1. [First step]
2. [Second step]
3. [Third step]
</instructions>
<requirements>
- [Must-have 1]
- [Must-have 2]
</requirements>
<constraints>
- [What NOT to do]
- [Tone, length, format limits]
</constraints>
<examples>
<example>
<input>[sample input]</input>
<output>[the right answer]</output>
</example>
</examples>
<grounding_rules>
- If you don't know, say "I don't know" rather than guessing.
- Think step-by-step before answering.
- Mark uncertain claims as "likely" or "uncertain".
- When using a document I provided, quote the relevant passage before drawing a conclusion from it.
</grounding_rules>
<output_format>
[Exact shape: headings? bullets? code? word count?]
</output_format>
<success_criteria>
- [Test 1]
- [Test 2]
</success_criteria>Every source cited or paraphrased in this workshop. Anything not in this list was either common knowledge or a direct observation — flag it and I'll add the source.
reprompt git repo at reference/standard.md. The XML skeleton in Part 2, the block-by-block rationale in Part 3, and the reprompt skill described in Part 7 all originate here.<grounding_rules> block.