Prompt Engineering in Practice: Structured Patterns for Controllable Output

Prompt engineering is not "try a different phrasing" — it is a set of reusable patterns. This guide covers four core techniques: role definition, few-shot examples, chain-of-thought reasoning, and output format constraints. Each includes a copy-ready prompt skeleton, plus a combination table for common scenarios.

Technique one: role definition

Role definition influences the model's knowledge focus, tone, and answer boundaries. It does not change the model's capability, but it changes how the model "positions itself" when answering.

# Basic
You are a technical documentation writer.

# Enhanced (with constraints)
You are a technical documentation writer.
- Your target audience is developers with 3 years of experience
- Avoid undefined abbreviations
- Explain each concept in one sentence on first mention
- Use TypeScript for code examples

Technique two: few-shot examples

Few-shot gives the model 2-3 input-output pairs in the prompt, so it learns your output pattern.

Rewrite the following product descriptions as image generation prompts.

Example:
Input: A wireless earbud
Output: A sleek wireless earbud floating against a gradient background, studio lighting, product photography

Input: A ceramic coffee cup
Output: A ceramic coffee cup with steam rising, warm morning light, kitchen counter

Now rewrite:
Input: A mechanical keyboard
Output:

Technique three: chain-of-thought (CoT)

CoT makes the model show its reasoning before giving an answer. This significantly improves accuracy on math, logic, code review, and other complex tasks.

Reason through the following problem step by step, then give the final answer.

Question: A team of 5 people needs to complete 3 tasks each. Each task takes 2 hours.
If the team works 8 hours per day, how many days will it take to complete all tasks?

Technique four: output format constraints

Make the model output parseable formats directly (JSON, tables, templates), eliminating the cost of parsing free-form text.

Analyze the following code and return the result in this JSON format:
{
  "issues": [{"line": <line_number>, "description": "<description>", "severity": "<low|medium|high>"}],
  "summary": "<one-sentence summary>"
}

Output only the JSON, no other text.

Code:
<paste code here>

A practical checklist before shipping

1. Test with a fixed eval set: 30-50 items covering typical, edge, and boundary cases. Record pass rate per category.
2. Check output format: for JSON tasks, parse every output and count parse failures. For free-text tasks, check length and tone consistency.
3. Measure token consumption: average and p95 across the eval set. A prompt that doubles token count may not be worth a small quality gain.
4. Test with temperature 0 and 0.7: some prompts only produce reliable output at low temperature.
5. Review edge cases: empty input, very long input, mixed languages, ambiguous instructions. These are where prompts break.
6. Document the prompt version: date, changes, eval scores. This prevents "what changed?" confusion three weeks later.
7. Check for prompt injection vulnerability: if the prompt includes user-provided content, test whether malicious input can override the system instructions.

A prompt that passes all seven checks is production-ready.

Common mistakes and how to fix them

These are the most common prompt engineering mistakes, with practical fixes:

1. Vague instructions. "Summarize this document" is vague — how long, what format, what tone? Fix: add specific constraints ("Summarize in 3 bullet points, max 20 words each, focusing on action items").

2. Contradictory instructions. "Be creative but follow this exact template" is contradictory — creativity means deviating from templates. Fix: remove the contradiction by deciding which constraint matters more.

3. Missing output examples. Without examples, the model guesses your expected format. Fix: add 1-2 few-shot examples showing exactly what good output looks like.

4. Too many constraints at once. Ten rules in one system prompt dilutes attention. Fix: separate into a system prompt (3-5 stable rules) plus task-specific instructions in the user message.

5. Not testing edge cases. A prompt that works on 90% of inputs but fails on 10% is not production-ready. Fix: add edge case items to the eval set and test explicitly.

6. Ignoring token count. A 2000-token prompt with 20-token output is 99% overhead. Fix: trim the system prompt, remove redundant examples, or compress history.

7. Assuming one prompt fits all models. A prompt optimized for GPT may underperform on Qwen or DeepSeek. Fix: test the same prompt across models and adjust per model.

Measuring improvement

To know whether a prompt change actually helped, measure these three numbers before and after:

1. Pass rate on eval set — the percentage of items that meet all checkpoints
2. Average output length — catches prompts that suddenly produce much shorter or longer outputs
3. Token consumption per call — catches prompts that grew without adding value

Record all three in a spreadsheet with columns for prompt version, date, and notes. After 3-4 iterations you will see patterns: which constraints help, which hurt, and which have no effect. This is the evidence that turns prompt engineering from trial-and-error into engineering.

When to rewrite from scratch

Sometimes a prompt has accumulated so many patches that a rewrite is faster than another iteration. Signs it is time:

• The system prompt exceeds 500 tokens and every new rule seems to conflict with an existing one
• The few-shot examples cover the same pattern three times because no single example covers the edge case
• You cannot explain why the prompt includes a specific instruction

When this happens, start with a blank file, write the three most important constraints from memory, test on the eval set, and only add what the eval says is missing. This usually produces a shorter, clearer prompt that performs as well as or better than the accumulated version.

Prompt versioning

Treat prompts like code — version them, test them, and document changes:

1. Store prompts in files (JSON/YAML/text), not hardcoded in application logic. This makes it easy to swap, test, and diff.
2. Name each version (e.g., v1.0-baseline, v1.1-added-fewshot) and record what changed.
3. Run the eval set before and after every change; keep the results alongside the prompt version.
4. Rollback is a file revert, not a code change — if v1.1 underperforms v1.0, switch back by pointing to the old file.

# prompts/classification.yaml
version: "1.2"
system_prompt: |
  You are a document classification assistant.
  Categories: technical, business, creative, other
  Output only the category name.
few_shot:
  - input: "Quarterly earnings report"
    output: "business"
  - input: "How to center a div in CSS"
    output: "technical"
  - input: "A poem about autumn"
    output: "creative"
parameters:
  temperature: 0
  max_tokens: 16

This structure makes the prompt auditable, testable, and shareable across a team.

Handling edge cases

Prompts that work on typical inputs often fail on edge cases. Test with:

• Empty or very short input: does the model handle it gracefully or hallucinate content?
• Mixed languages: if the input contains unexpected language switches, does the model maintain coherence?
• Ambiguous instructions: if the input could be interpreted multiple ways, does the model ask for clarification or guess?
• Very long inputs near the context limit: does the model stay coherent or degrade?

These are the cases where prompt quality matters most. A prompt that only works on ideal inputs is not production-ready.

Combining the four techniques

FAQ

Related reading

• JSON Structured Output Guide — deeper dive on format constraints
• LLM Evaluation Methodology — measuring prompt effectiveness
• Context Engineering Guide — managing the window budget
• Agent Framework Guide — prompt design in agent systems
• Pricing — live cloud pricing