Prompt Engineering I — The Briefing Memo
- Write system prompts structured like job descriptions: role, context, instructions, constraints, format
- Demonstrate that clarity and specificity beat "magic words" with before/after comparisons
- Use XML tags to separate instructions from data and explain why the separation matters
- Construct few-shot examples that pull their weight, and identify examples that mislead
- Explain the instruction hierarchy: system over user over retrieved/quoted content
| Spaced-rep warm-up: due cards (API, cost, streaming) | 10 min |
| ELI5 + tech read: the memo skeleton & hierarchy | 20 min |
| Guided: interactive tutorial chapters | 25 min |
| Guided: rebuild the bad prompt, three versions | 25 min |
| Practice: docs-QA memo with grounding rule | 20 min |
| Project: prompt library + quiz + flashcards | 20 min |
Builds on: Day 106 — The request & the system field · Day 100 — Why models follow instructions (SFT/RLHF) · Day 104 — Context windows & placement effects
You hire a brilliant new contractor — the polymath — who knows nearly everything, works instantly, and has one quirk: they do exactly what the briefing memo says, no more, and fill every gap in the memo with their own guesses. Hand them "make this better" and you get their taste, not yours. Hand them a proper brief — who they are working for, what the situation is, what to do, what never to do, and what the deliverable looks like — and the same contractor becomes exactly the specialist you needed.
Prompt engineering is technical writing for a very literal, very capable reader. Three habits carry most of the value. Be concrete: "reply in 2-3 sentences, no marketing language, cite the policy section" beats "be concise and professional." Show, don't only tell: two or three worked examples teach format and judgment faster than paragraphs of description — like handing the contractor a model deliverable. And label your materials: wrap customer text, documents, and data in clearly marked containers so the contractor never confuses the stuff to be processed with the instructions for processing it. That last habit, you will learn on Day 132, is also the beginning of security.
Prompting is the highest-leverage, lowest-cost intervention in the entire stack — minutes to change, no retraining, and routinely worth more than a model upgrade. For an FDE it is doubly central: prompts encode the customer's business rules, so writing and iterating them WITH customers is a core delivery activity. And the discipline you learn today — explicit contracts, separated data, tested examples — is what makes prompts maintainable team artifacts rather than one person's incantations. Weak prompting also compounds into every later system: a sloppy system prompt makes RAG answers unfaithful and agents erratic.
Guided practice
The interactive tutorial, selectively
25 min- Open Anthropic's interactive prompt-engineering tutorial (resource link) and work the chapters on clarity/directness, role prompting, XML structure, and few-shot examples. Skim the rest — you will meet chain-of-thought tomorrow.
- For each chapter, copy ONE exercise prompt into your notes with the before/after behavior you observed.
- Extract three personal rules from what you saw — phrased as testable claims ("naming an output length changes verbosity more than the word concise"), not slogans.
Before/after: rebuild a bad prompt
25 min- Start with this deliberately weak prompt: "Summarize customer feedback and tell me if it's important."
- Using your Day-107 wrapper, run it against the three feedback samples in the starter (paste them as the user message) and save outputs.
- Rebuild it as a full memo: role (support triage analyst), context (SaaS product, feedback triage), instructions (classify sentiment, extract feature requests, flag churn risk), constraints (no invented details; quote the customer for evidence), format (a fixed template with labeled fields), all with the feedback wrapped in <feedback> tags.
- Rerun the same three samples. Diff the outputs: consistency of format across samples, presence of evidence quotes, hallucinated details.
- Add a two-example <examples> block and run a third time. Record which improvement came from structure and which from examples — that attribution habit is tomorrow's A/B discipline in miniature.
On your own
The memo for your own project
20 minWrite a complete production-grade system prompt for a docs-QA assistant answering questions about YOUR llm-toolkit repo's README (paste the README as context in <docs> tags). Requirements: full memo skeleton (role, context, instructions, constraints, format), a grounding rule ("answer only from <docs>; say 'not covered in the docs' otherwise"), and one few-shot example of a question the docs cannot answer being correctly declined.
Test it with three questions: one answerable, one ambiguous, one outside the docs. Score honestly against your own constraints.
Hints: the grounding rule + declined-question example is the pattern at the heart of your Day-119 capstone; if the outside-docs question gets answered anyway, strengthen the constraint wording and note which phrasing finally held.
Start the prompt library
Create prompts/ in your llm-toolkit repo, treating prompts as code: each prompt is a versioned markdown file with frontmatter-style metadata (name, version, model, date, owner) and the memo skeleton as its sections. Seed it with three artifacts from today: the triage prompt (v1 weak, v2 structured, v3 with examples — keep all three for history), your docs-QA prompt, and a TEMPLATE.md encoding the skeleton with a checklist. Commit with meaningful messages per version. Tomorrow adds a change-checklist and A/B results; by Day 141 this library gets regression-tested in CI.
Common mistakes & misconceptions
- Hunting for magic words instead of adding specificity. "You are a world-class expert" adds little; naming the audience, the format, and the failure modes adds a lot.
- Prompting only with adjectives: concise, professional, accurate. Convert each to a measurable instruction — length caps, banned phrases, required citations.
- Mixing data into instructions unlabeled. Untagged pasted text invites the model to treat content as commands — a correctness bug today, a security hole on Day 132.
- Few-shot examples that contradict the instructions. When examples and prose disagree, examples usually win — audit them like code.
- One mega-instruction blob with no order. Models weight structure; numbered instructions with the most important first outperform walls of text.
- Editing prompts in place with no history. Version every change — when quality shifts next month you need the diff (formalized tomorrow).
Q1. Why do the docs recommend XML tags in prompts?
Q2. Your few-shot examples show 4-bullet outputs but the instructions say "at most 2 bullets." What most likely happens?
Q3. The instruction hierarchy orders trained priority as…
Go deeper — curated resources
- Read a real production system prompt — Anthropic publishes the system prompts used by claude.ai. Read one end-to-end and map it against the memo skeleton — note how much of it is constraints and format rather than role.
- Tutorial chapters done with three testable personal rules extracted
- Triage prompt improved across three measured versions
- Docs-QA prompt passes all three test questions including the decline
- Prompt library committed with template and version metadata
- Quiz ≥ 2/3
← Back: The system field you are now engineering was introduced on Day 106; WHY models obey it traces to Day 100's SFT and preference tuning; placing instructions at context edges applies Day 104's lost-in-the-middle finding.
Forward →: Day 109 adds reasoning techniques, output contracts, and A/B discipline to this foundation. The grounding pattern becomes the capstone's core on Day 119, the tagged-data separation becomes injection defense on Day 132, and the library you started gets CI gates on Day 141.
Unlocks: D109 Prompt Engineering II — Memos That Survive Contact · D110 Structured Outputs — Forms, Not Essays · D112 Week 16 Checkpoint: The Prompt Lab