Where the system prompt sets standing policy, the user prompt carries the live job: questions, documents, parameters, and turn-specific constraints. Good products keep user messages clear, complete, and free of secrets that belong in serverside config.
User prompts also feed prompt chaining steps and are the main surface for injection risks addressed in guardrails.
Learning Objectives
By the end of this lesson, students should be able to:
- Define the user prompt in chat and completion APIs.
- Structure user messages: goal, inputs, constraints, output ask.
- Template user prompts with variables without leaking instructions.
- Place retrieved context safely beside the question.
- Distinguish developer-built user templates from end-user free text.
- Prepare user turns for evaluation harnesses.
A user prompt is the message (role user) that states the current request—query, task inputs, and any per-turn context—that the assistant should respond to under the constraints of the system prompt and conversation history.
A Reliable User-Message Skeleton
What success is.
Data / documents.
Length, tone, scope.
Format reminder.
| Pattern | Example cue | Use when |
|---|---|---|
| Direct question | “What is …?” | QA / chat |
| Task + payload | “Classify this:” + text | Pipelines |
| Context + question | Docs then ask | RAG |
| Template fill | Slots: {name}, {date} | Apps |
Do
- One primary goal
- Label pasted context
- Repeat critical format if needed
Don’t
- Hide the ask in noise
- Paste secrets / API keys
- Contradict system safety
Template tip
- Escape user-supplied text
- Keep instructions outside slots
- Log redacted inputs
Practical Templated User Prompt
Strengths
- Clear per-request control
- Natural place for RAG payloads
- Easy to A/B in eval sets
Tradeoffs
- Untrusted text can inject instructions
- Long contexts raise cost/latency
- Poor structure confuses the model
“Everything the human types should be forwarded raw as the only message.” Products should wrap end-user text in a developer template that restates the goal and labels context. Raw free text alone skips structure from basic prompting craft and weakens evaluation.
Knowledge Check
- Short Answer: What is a user prompt? Answer: The per-turn request message with the current goal and inputs.
- True/False: API keys belong in the user prompt. Answer: False.
- Multiple Choice: A solid skeleton includes: (a) goal, inputs, constraints, output ask, (b) only emojis, (c) raw GPU dumps. Answer: (a).
- Short Answer: Why label
<context>vs<question>? Answer: Separates evidence from the ask for the model and for safety. - True/False: Retrieved documents are often placed in the user message. Answer: True.
- Multiple Choice: Template slots should: (a) hold data, not rewrite system policy, (b) replace auth, (c) disable logging forever. Answer: (a).
- Short Answer: Name one injection risk surface. Answer: Untrusted text inside the user/context payload.
- Short Answer: How do user prompts relate to chaining? Answer: Each chain step is often a new user (or crafted) message.
- Multiple Choice: Eval harnesses primarily vary: (a) user inputs/tasks, (b) silicon doping, (c) cable color. Answer: (a).
- True/False: System and user roles should stay complementary, not duplicated walls of text. Answer: True.
Key Takeaways
- User prompts carry the live goal and inputs.
- Template structure beats raw forwarding.
- Label context; watch injection and token cost.
- Next: Prompt Chaining.
Hands-on: Rewrite three messy user messages into Goal/Inputs/Constraints/Output form; score answer quality.
Discussion: When should multi-turn chat history be summarized into a fresh user prompt?
Recap: User prompts state the job; templates make that job reliable. Continue with Prompt Chaining.