Prompt Formatting: Questions, Instructions, and Templates
What Is Prompt Formatting? Prompt formatting is the way the text of a prompt is arranged: whether it is written as a question, a command, a labeled pattern, or a structured document with sections.
Lesson 3 introduced the basic prompt styles. This lesson goes further and explains how the layout of a prompt affects the response, how to choose a format for a task, and how to turn a good prompt into a reusable template.
The same request can be formatted in very different ways:
As a question:
What is the main topic of this paragraph? "Docker packages an application with its dependencies so it runs the same way on every machine." As an instruction:
Identify the main topic of the paragraph below in five words or fewer.
Paragraph: "Docker packages an application with its dependencies so it runs the same way on every machine." As a template:
Paragraph: "Docker packages an application with its dependencies so it runs the same way on every machine." Main topic (max 5 words): All three can produce a correct answer. They differ in how much control they give you and how easy they are to reuse.
Why Formatting Affects the Response A model continues text in the way that best fits the patterns it has learned (Lesson 2). Formatting is part of that pattern:
A conversational question tends to produce a conversational answer. A precise command with constraints tends to produce a focused result. A labeled pattern tends to be continued with the same labels and structure. A prompt with headings and sections tends to produce a structured, organized response. The style of the prompt influences the style of the output. A casual, unstructured prompt often gets a casual, unstructured answer. A clearly organized prompt often gets an organized answer.
This means formatting is not cosmetic. It is one of the ways you guide the model.
Format 1: Question Format What It Is The prompt is written as a natural question.
Why does Python use indentation instead of curly braces? When to Use It Quick factual or conceptual questions Exploratory conversations, where you do not yet know what kind of answer you need Situations where the expected answer is obvious from the question Strengths and Limitations Strengths Limitations Natural and fast to write No control over length, depth, or format Works well for simple, well-defined questions Ambiguous questions get generic answers Good for exploring a topic Difficult to reuse consistently in applications Improving a Question Without Changing Its Format You can keep the question style and still add control:
Why does Python use indentation instead of curly braces? Answer in 3 sentences for someone who already knows JavaScript. The question remains, but the added audience and length requirements remove two major sources of variation.
Format 2: Question-and-Answer (Q&A) Format What It Is The prompt uses explicit Q: and A: labels. It may contain earlier question-answer pairs as examples, and it ends with an open A:.
Q: What does HTML stand for? A: HyperText Markup Language
Q: What does CSS stand for? A: Cascading Style Sheets
Q: What does SQL stand for? A: Expected output:
Structured Query Language Why It Works The earlier pairs show both the style of answer (the expansion only, no explanation) and the pattern (Q: followed by A:). The final A: cue marks exactly where the answer begins. The model continues the established pattern instead of writing a paragraph.
When to Use It Short factual answers with a consistent style Building quiz or flashcard content Demonstrating answer length and tone through examples Format 3: Instruction Format What It Is The prompt is written as a command that defines a task, usually with requirements.
Write a docstring for the Python function below. Use the Google docstring style, include an Args section and a Returns section, and keep the summary line under 80 characters.
def calculate_gst(amount, rate=0.18): return round(amount * rate, 2) Possible output:
def calculate_gst(amount, rate=0.18): """Calculate the GST for an amount at the given rate.
Args: amount: The base amount before tax. rate: The GST rate as a decimal. Defaults to 0.18 (18%).
Returns: The GST amount rounded to 2 decimal places. """ return round(amount * rate, 2) Example Explanation The instruction names a specific style ("Google docstring style"), required sections, and a length limit for the summary line. The result includes exactly those elements. The phrase "18%" was added by the model as a helpful explanation of 0.18; it is consistent with the code, but you should still read generated documentation to confirm it describes the code correctly. When to Use It Instruction format is the default for practical work: generating, transforming, analyzing, or extracting content. It gives the most direct control over the task and its requirements.
Format 4: Structured (Sectioned) Format What It Is The prompt is organized into labeled sections using Markdown headings, XML-style tags, or both.
Using Markdown headings:
Role
You are a code reviewer for a Django team.
Task
Review the view function below for security problems.
Rules
- Report only security problems, not style issues.
- For each problem, give the line number, the risk, and the fix.
- If there are no problems, reply "No security issues found."
Code
1: def profile(request): 2: user_id = request.GET["id"] 3: user = User.objects.raw(f"SELECT * FROM auth_user WHERE id = {user_id}")[0] 4: return render(request, "profile.html", {"user": user}) Using XML-style tags:
You are a code reviewer for a Django team.
Review the view function in for security problems.
- Report only security problems, not style issues.
- For each problem, give the line number, the risk, and the fix.
- If there are no problems, reply "No security issues found."
... Why It Works Each part of the prompt has a clear label, so the model can tell the role, task, rules, and data apart. Instructions can refer to sections by name: "the function in ". Humans can read, review, and edit long prompts more easily. In this example, a correct review identifies line 3: user input from the URL is inserted directly into a raw SQL query, which allows SQL injection. The fix is to use the ORM, such as User.objects.get(id=user_id), or a parameterized query. A thorough review may also note that line 2 raises an error when the id parameter is missing.
Markdown Headings vs XML Tags Aspect Markdown Headings XML-Style Tags Readability for humans Very good Good Clear start and end of a section Section ends at the next heading Explicit opening and closing tags Best for Instructions and rules Data, documents, and nested content Referencing in instructions "the Rules section" "the text inside " A common and effective approach is to use Markdown headings for instructions and XML-style tags to wrap data. There are no special or required tag names; choose descriptive names such as
, , or and use them consistently.
When to Use It Prompts longer than a few sentences Prompts with several kinds of content: rules, examples, and data Prompts maintained by a team or reused in applications Format 5: Templates What a Template Is A prompt template is a prompt with fixed text and clearly marked placeholders for the parts that change.
Write a {length}-word product description for the following product.
Product name: {product_name} Key features: {features} Target customer: {audience}
Tone: {tone} Do not mention prices or discounts. Each {placeholder} is replaced with real values before the prompt is sent.
Why Templates Exist Once you have refined a prompt that works, you rarely want to write it from scratch again. A template:
Preserves what works: the tested structure, constraints, and wording stay the same. Produces consistent results: every request follows the same pattern. Separates fixed logic from variable data: you change only what should change. Makes prompts shareable: a team can use the same template. Filling a Template Manually Write a 60-word product description for the following product.
Product name: StudyLamp Pro Key features: adjustable brightness, USB charging, eye-comfort mode Target customer: college students who study late at night
Tone: friendly and practical Do not mention prices or discounts. Template Design Rules
Keep instructions fixed and data variable. The rule "Do not mention prices or discounts" is part of the template because it should apply to every product. If you made it a placeholder, users could accidentally remove an important constraint.
Label every placeholder clearly. Product name: {product_name} shows both the human reader and the model what each value means.
Decide what happens when a placeholder is empty. If {features} could be empty, add a rule such as: "If no features are listed, describe only the product type and do not invent features."
Do not let placeholders break the structure. If a value could contain text that looks like instructions or contains your delimiter, wrap it in tags. User-provided values are especially important to delimit (see Lesson 7).
Templates are developed further in Lesson 36 (task-oriented templates) and Lesson 38 (filling templates with variables in code).
Choosing the Right Format Situation Recommended Format A quick question in chat Question Short answers in a consistent style Q&A with examples A single task with requirements Instruction A long prompt with rules, examples, and data Structured sections A prompt you will reuse with different data Template A prompt inside an application Template with structured sections Progression in Practice Prompts often move through these formats as a task matures:
Question in chat (exploring) ↓ Instruction with requirements (getting reliable results) ↓ Structured sections (as rules and examples grow) ↓ Template (reused for many inputs) Example of the Progression Stage 1 — Question:
Can you write a meta description for my blog post about Python virtual environments? Stage 2 — Instruction:
Write an SEO meta description for a blog post about Python virtual environments. Keep it under 155 characters, include the phrase "Python virtual environment", and describe what the reader will be able to do after reading. Stage 3 — Structured:
Task
Write an SEO meta description for the blog post described below.
Requirements
- Under 155 characters
- Include the exact phrase given in "Focus phrase"
- Describe what the reader will be able to do after reading
- Do not use clickbait phrases such as "You won't believe"
Post
Title: How to Use Python Virtual Environments Focus phrase: Python virtual environment Summary: Explains venv creation, activation, installing packages, and requirements.txt.
Output
Return only the meta description text. Stage 4 — Template:
Task
Write an SEO meta description for the blog post described below.
Requirements
- Under 155 characters
- Include the exact phrase given in "Focus phrase"
- Describe what the reader will be able to do after reading
- Do not use clickbait phrases such as "You won't believe"
Post
Title: {title} Focus phrase: {focus_phrase} Summary: {summary}
Output
Return only the meta description text. Explanation of the Progression Stage 1 is fine for a single attempt but leaves length, keyword use, and focus undefined. Stage 2 adds requirements, which makes the output usable. Stage 3 separates requirements from data and adds the output rule, which prevents explanatory text around the description. Stage 4 replaces the specific post with placeholders. The tested structure can now be reused for every post on the blog. Formatting Details That Matter Whitespace and Line Breaks Blank lines between sections make boundaries clearer for both the model and the reader. A dense block of text with no line breaks hides structure.
Consistent Labels If an example uses Input: and Output:, the actual task must use the same labels. Changing to Text: and Result: breaks the pattern.
Numbered vs Bulleted Rules Use numbered lists when order matters or when you want to refer to rules by number ("follow rule 3"). Use bullet lists for independent requirements. Match the Prompt Style to the Desired Output Style If you want a response without Markdown, writing the prompt in heavy Markdown can make Markdown output more likely. If you want a formal document, write the prompt formally. Because the model continues patterns, the prompt's style provides a signal in addition to your explicit instructions.
Common Mistakes Mistake 1: Using Only Questions for Production Tasks What it is: Building an application feature on a bare question such as "What is the sentiment of this review?"
Why it happens: The question worked in a chat test.
What it causes: Varying formats and lengths that code cannot handle reliably.
How to fix it: Convert to an instruction with an output format, then into a template.
Mistake 2: Breaking an Established Pattern What it is: Showing examples with one set of labels and then using different labels for the actual task.
Why it happens: Labels are edited in one place but not the other.
What it causes: The model may not recognize the task as part of the pattern, so the output format becomes inconsistent.
How to fix it: Use identical labels in examples and in the final task.
Mistake 3: Over-Structuring Simple Prompts What it is: Using headings and sections for a one-line question.
Why it happens: Applying a template habit to every request.
What it causes: More tokens and more effort with no improvement.
How to fix it: Match structure to complexity. Short tasks need short prompts.
Mistake 4: Turning Rules Into Placeholders What it is: Making important constraints variable, such as {rules}, so each request supplies its own.
Why it happens: A desire for maximum flexibility.
What it causes: Constraints are forgotten or changed accidentally, and the template stops producing consistent results.
How to fix it: Keep stable rules fixed in the template. Make only the true data variable.
Mistake 5: Inconsistent Section Names What it is: Writing "the article" in the instruction while the data is labeled .
Why it happens: Different parts of the prompt were written at different times.
What it causes: The model may not connect the instruction to the right content.
How to fix it: Refer to sections by exactly the labels you used.
Best Practices Use questions for exploring and instructions for working. Questions are fast; instructions give control.
Add structure as prompts grow. Once a prompt has several rules, examples, or data sections, organize it with headings and tags.
Use Markdown headings for instructions and tags for data. This combination keeps prompts readable and boundaries explicit.
Turn proven prompts into templates. After a prompt works reliably, replace the changing parts with clearly labeled placeholders.
Keep rules fixed and data variable in templates. Only the content that genuinely changes should be a placeholder.
Keep labels consistent. The same concept should have the same label everywhere in the prompt.
Write the prompt in the style you want back. The format of the prompt influences the format of the answer.
Try It Yourself Exercise 1: One Request, Four Formats Write the following request in question, Q&A, instruction, and structured formats: Get a one-sentence definition of "load balancer" for a beginner. Run each version three times and compare which format gives the most consistent results.
Exercise 2: Build a Q&A Pattern Create a Q&A prompt with three example pairs that convert HTTP status codes to short meanings, such as Q: 404 / A: Not Found. End with a new code, such as Q: 503, and an open A:. Check whether the model follows the short-answer style.
Exercise 3: Create a Template Take a prompt you use often, such as writing a social media post or summarizing a meeting. Refine it until it works well, then:
Organize it into sections. Identify which parts change each time and replace them with placeholders. Add a rule for empty or missing placeholder values. Use the template with three different sets of values and compare the consistency of the results.