What This Template Covers
The LLM prompt engineering template covers five structured components that together define a complete prompt design and management system. The system prompt structure section provides a template for the system-level instructions that establish the model's role, constraints, output format, and behaviour rules. The system prompt is the highest-leverage part of an LLM product's design. A well-structured system prompt reduces output variability, improves compliance with format requirements, and makes the model's behaviour more predictable and testable. The few-shot example format section covers how to design, select, and structure examples included in the prompt to demonstrate the expected input-output pattern. Few-shot examples are particularly effective for tasks where the output format or style is difficult to specify purely through instructions. The chain-of-thought pattern section covers when and how to use structured reasoning steps to improve model output quality on tasks that require multi-step reasoning, analysis, or complex decision-making. The output schema definition section covers how to specify the expected output format, particularly for structured outputs (JSON, markdown tables, specific field formats) where downstream parsing depends on consistency. The prompt versioning log section covers how to track prompt changes, the tests that justified each change, and the impact on output quality. Without versioning, prompt management becomes chaotic as products grow.
How to Use This Template Step by Step
Step one: define the task clearly before writing a single word of the prompt. What is the model being asked to do? What are the inputs? What are the expected outputs? What are the constraints on outputs (length, format, tone, topics to avoid)? Write this as a task specification before opening a prompt editor. Step two: write the system prompt. A good system prompt typically has four parts. The role definition names what the model is and what it does: "You are a contract analysis assistant that helps legal teams identify key clauses in commercial agreements." The context section provides any background the model needs to perform the task well. The instruction section specifies what the model should do with each input. The constraints section specifies what the model must not do: topics it should not address, formats it must not use, and the behaviour when the input is outside scope. Step three: test the system prompt against at least ten representative inputs. Note the cases where the output is wrong, unexpected, or inconsistent. These become the basis for few-shot examples and prompt refinements. Step four: select few-shot examples based on the problem cases you identified in step three. Good few-shot examples are representative of the input distribution, cover the edge cases that cause problems, demonstrate the correct output format precisely, and are as short as possible while still being effective. Step five: evaluate whether chain-of-thought reasoning is needed. For tasks that require analysis, comparison, or multi-step reasoning, adding an instruction to reason step by step before producing the final answer typically improves output quality. For simple classification or extraction tasks, chain-of-thought adds latency and cost without proportionate benefit. Step six: define the output schema. If the product depends on structured output, specify the exact format required: field names, data types, nesting structure, and how optional or missing values are represented. For JSON output, include a schema definition. Test that the model reliably produces schema-compliant output before depending on it in production. Step seven: set up the versioning log. For each prompt version, record: version number, date, what changed, what problem the change was addressing, the test results before and after the change, and who approved it. Even a simple spreadsheet is sufficient. The goal is to be able to roll back to a previous version if a change causes unexpected regressions.
Section-by-Section Walkthrough
The system prompt structure section in the template uses a block format for clarity. The role definition block is one to two sentences. The context block provides any static background information the model needs. The instruction block describes the task using numbered steps if there are multiple sub-tasks. The constraints block uses bullet points for clarity. The format block specifies the output format. An important principle: the system prompt should be written for the model's understanding, not for human readability. Clear, direct language with explicit instructions produces better results than flowery descriptions. Models respond better to "always return JSON with the following fields" than to "please try to format your output in a structured way." The few-shot example section should include examples in the same input-output format that the production system uses. Do not write examples in a different format from the actual API call structure. Each example should be complete: a full input and a full correct output. Include at least one example of each edge case type that the production system will encounter. The chain-of-thought section should specify where in the output the reasoning appears. Two common patterns: scratchpad reasoning (model reasons first, then produces the final answer, with the reasoning discarded or stored separately) and inline reasoning (model reasons step by step as part of the output, which the user sees). For production systems, scratchpad reasoning is usually preferable because it keeps the user-facing output clean while improving model performance. The output schema section should be as specific as a database schema. Define every field, its type, whether it is required or optional, its permitted values if constrained, and an example value. If using JSON schema, include the full JSON schema definition. If using markdown, specify the exact heading structure, list format, and any required fields. The versioning log section should be maintained as a plain-text file in the project repository alongside the prompt files. This makes it part of the code review process. Every prompt change should go through the same review and testing process as a code change, because in LLM products, prompts are code.
Common Mistakes This Template Prevents
The most common prompt engineering mistake is writing prompts reactively rather than systematically. Teams add sentences to prompts when problems emerge, without testing whether the fix solves the problem without introducing new ones. Over time, the prompt becomes a patchwork of reactive fixes that are internally inconsistent. This template's versioning and testing approach prevents accumulation of untested changes. The second mistake is treating the system prompt as confidential and therefore not reviewing it systematically. Prompts should be treated as code and reviewed with the same rigour. Code review for prompts means checking for internal contradictions, testing edge cases, and validating that the prompt produces the specified output reliably. The third mistake is using few-shot examples that do not reflect the actual distribution of real inputs. Examples chosen for their clarity rather than their representativeness teach the model to handle ideal inputs well while struggling with the messier real inputs it will actually receive. The fourth mistake is not defining a fallback behaviour. Every production LLM system will sometimes receive inputs it cannot handle correctly: inputs in unexpected languages, inputs that violate the expected format, or inputs that are adversarially designed to make the model misbehave. The system prompt should specify explicit fallback behaviour for these cases rather than relying on the model's default behaviour.
Customisation Tips for Different Project Types
For customer-facing chatbots and assistants, the constraints section of the system prompt is particularly important. Specify: topics the assistant must not discuss, how the assistant should handle requests for information it does not have (rather than hallucinating), how the assistant should handle abusive inputs, and what the assistant should say if asked to do something outside its role. These constraints prevent the failure modes that cause reputational damage in production. For document analysis products, the system prompt should include explicit instructions about what to do when the document is poorly formatted, incomplete, in an unexpected language, or larger than the context window. These are common real-world conditions that the prompt design must handle gracefully. For products that use AI to make recommendations or assessments that affect users (content recommendations, credit risk indicators, job screening), the system prompt should include fairness constraints and explicit instructions to avoid protected characteristic-based reasoning. Under the Equality Act 2010, automated systems that produce discriminatory outcomes can create legal liability regardless of intent. For multi-lingual products, create separate prompt versions for each supported language rather than relying on the model to translate instructions on the fly. Prompts written in the language of the task produce more reliable and culturally appropriate outputs than prompts written in English for tasks performed in other languages.