Prompting That Survives Contact
System prompts, few-shot examples, and output contracts — prompting as engineering, not incantation.
A production prompt has an anatomy: role and goal (who the model is, what done means), constraints (what it must never do), the task input clearly delimited, and the output contract (exact format, with an example). Delimiting matters more than people expect — wrap user input in tags like <user_input> so the model can tell instruction from data. That single habit is also your first line of defense against prompt injection, which Module 6 covers properly.
Few-shot examples are the highest-leverage prompting tool: two or three input→output pairs teach format and edge-case handling better than three paragraphs of description. Pick examples that encode your hard cases — the ambiguous input, the empty input, the almost-but-not-quite match. If you find yourself writing 'be careful about X' twice, replace the warning with an example demonstrating X handled correctly.
Two habits separate prompts that survive production from demo prompts. First, version them like code — prompts live in files, get code review, and have changelogs, because a one-word edit can shift behavior measurably. Second, test them against a fixed set of inputs before shipping changes (Module 5 turns this into proper evals). 'It worked when I tried it' is the prompting equivalent of 'it compiles.'