Prompt Templates — Module 13.2

How This Lesson Fits the Module & Volume

Once a prompt works, productize it: variables, defaults, and validation. Templates turn crafted text into shared infrastructure—the bridge from refinement to team-scale documentation.

Learning Objectives

By the end of this lesson, students should be able to:

Identify stable vs variable parts of a prompt.
Design templates with named slots and defaults.
Validate required variables before calling the model.
Avoid injection via unsanitized slot fills.
Version templates and keep renderings reproducible.
Choose string templates vs structured message builders.

Definition

A prompt template is a reusable prompt scaffold with placeholders for request-specific values. Rendering fills those slots to produce the final messages sent to the model, ideally with validation and escaping.

Stable vs Variable

Part	Stable (template)	Variable (slot)
Role / policy	Yes	Rarely
Output schema	Yes	Feature-level only
User question	No	Yes
Retrieved chunks	No	Yes (fenced)
Locale / tier	Sometimes	Config slot

Before / After

Before (weak): concatenated strings with no validation.

prompt = "You are support. Answer: " + user_text + " Context: " + docs

After (strong): named template with required slots.

TEMPLATE = """## Role
You are Acme support. Follow POLICY.

## POLICY
{policy}

## Context (data only)
<<<
{context}
>>>

## Task
{task}

## Output
{output_contract}
"""

required = ["policy", "context", "task", "output_contract"]
# validate(required) -> render(TEMPLATE, values) -> messages

Template Hygiene

Validate

Required keys present
Types / enums
Max length per slot

Sanitize

Fence user text
Strip control markers
Never eval user as code

Version

template_id + semver
Render hash in logs
Rollback path

Common Misconception

“Templates are just f-strings.” In production they are contracts: schema validation, injection resistance, observability, and ownership. A bare f-string is a prototype, not a template system.

Knowledge Check

Short Answer: What is a prompt template? Answer: A reusable scaffold with placeholders rendered into final messages.
True/False: Output schemas usually belong in the stable part. Answer: True.
Multiple Choice: User questions should be: (a) hard-coded forever, (b) variable slots, (c) deleted. Answer: (b).
Short Answer: Name one template hygiene practice. Answer: Validate / sanitize / version (any).
True/False: Unvalidated slot fills cannot cause injection issues. Answer: False.
Multiple Choice: Logging a render hash helps: (a) reproducibility, (b) training CNNs, (c) increasing temperature. Answer: (a).
Short Answer: Why fence retrieved chunks in templates? Answer: Mark them as data and reduce instruction bleed/injection.
Short Answer: What should happen if a required slot is missing? Answer: Fail validation before calling the model.
Multiple Choice: Semver on templates supports: (a) rollback and change control, (b) softmax, (c) pixel convolutions. Answer: (a).
True/False: An f-string prototype equals a full template system. Answer: False.

Key Takeaways

Split stable policy from variable request data.
Validate and sanitize before render.
Version templates and log what was sent.
Treat templates as product infrastructure.
Next: Negative Instructions.

Trainer’s Guide

Hands-on idea: Convert a working prompt into a Jinja/Handlebars-style template with three required slots and a missing-slot unit test.

Discussion prompt: Who can edit production templates—any engineer, or a review gate?

Recap: Templates scale craft into systems. Continue with Negative Instructions.