Module 13.1 taught what prompting patterns exist—zero-shot, few-shot, system prompts, and evaluation. Module 13.2 teaches the craft of writing those prompts so teams can ship reliable behavior.
Prompt structure is the blueprint: role, task, context, constraints, and output contract arranged so a model (and a teammate) can parse intent in one pass. Every later lecture—clarity, ordering, templates, documentation—refines a piece of this skeleton.
Learning Objectives
By the end of this lesson, students should be able to:
- Name the five production sections of a well-structured prompt.
- Separate durable policy (system) from per-request work (user).
- Rewrite a flat “wall of text” into labeled sections.
- Choose headings, bullets, or XML/Markdown delimiters for scannability.
- Explain why structure improves both model compliance and human review.
- Link structure to later craft topics: ordering, templates, and docs.
Prompt structure is the deliberate layout of instructions, context, examples, and output rules into clear sections so the model can locate each requirement and so engineers can version, review, and reuse the prompt as a product artifact.
The Five-Section Skeleton
Production prompts rarely succeed as a single paragraph. Treat the prompt like an API contract with named fields:
Who the assistant is and durable rules.
The single job for this call.
Facts, docs, or user data to use.
Must / must-not, tone, safety.
Format, schema, length, labels.
| Section | Lives best in | Changes how often? |
|---|---|---|
| Role / policy | System prompt | Rarely (product rules) |
| Task | User message or template slot | Every request type |
| Context | User message / RAG block | Every request |
| Constraints | System or shared template | Occasionally |
| Output contract | Template + validation code | Per feature |
Before / After: Flat vs Structured
Before (weak): everything mashed together—hard for the model and for code review.
After (strong): labeled sections with one job each.
Structural Patterns Teams Use
Markdown headings
- Fast for humans
- Works in chat UIs
- Easy to diff in git
XML tags
- Clear delimiters
- Good for long context
- See XML prompting
JSON contracts
- Machine-checkable output
- Pairs with validators
- See JSON prompting
“Structure is just formatting—the model ignores headings.” Instruction-tuned models are trained on structured docs and chat. Clear section labels reduce ambiguity and make conflicting rules easier to spot in review. Structure is a reliability tool, not decoration.
Knowledge Check
- Short Answer: List the five sections of the production prompt skeleton. Answer: Role/policy, task, context, constraints, output.
- True/False: Durable product policy usually belongs in the system prompt. Answer: True.
- Multiple Choice: Per-request retrieved documents belong in: (a) role, (b) context, (c) output schema. Answer: (b).
- Short Answer: Why is a flat “wall of text” risky in production? Answer: Requirements blur together, so the model and reviewers miss constraints.
- True/False: Output format rules should be left implied. Answer: False—specify them explicitly.
- Multiple Choice: XML tags in prompts mainly help: (a) GPU kernels, (b) delimit sections/context, (c) replace tokenization. Answer: (b).
- Short Answer: Name one benefit of structured prompts for teams. Answer: Easier code review, versioning, or reuse via templates.
- Short Answer: Where should the single primary task statement live? Answer: In a dedicated Task section (often the user message).
- Multiple Choice: Module 13.2 focuses on: (a) training CNNs, (b) craft of writing production prompts, (c) SQL indexing. Answer: (b).
- True/False: Structure improves human review as well as model compliance. Answer: True.
Key Takeaways
- Treat prompts as contracts: role, task, context, constraints, output.
- Put durable policy in the system layer; put request-specific work in the user layer.
- Labeled sections beat walls of text for models and teammates.
- Pick Markdown, XML, or JSON delimiters to match your stack.
- Next: Clarity & Specificity.
Hands-on idea: Give students a 120-word unstructured prompt and require a five-section rewrite without changing the intended task.
Discussion prompt: What belongs in system vs user when the same feature supports three product tiers?
Recap: Structure turns prompting from improvisation into an engineering artifact. Continue with Clarity & Specificity.