LLM Prompt Patterns: System Prompts and Reasoning Techniques

LLM prompt patterns are reusable ways to organise instructions and guide a model through a task. The useful patterns address unclear scope, inconsistent format, several dependent decisions or an answer that needs verification.

Choose a pattern because it improves measured behaviour. Adding a persona, a long reasoning request and several demonstrations to every prompt makes it harder to identify which part helps.

Write system prompts around observable behaviour

A system prompt can define the assistant's purpose, permitted sources, output expectations and response to missing information. Use concrete requirements where the task allows them.

You answer product return-policy questions.

Use the supplied policy passages and cite their clause IDs.
If the passages do not answer the question, state what is missing.
Do not confirm that a refund has been approved.
If the customer requests an action, return the action-request status
defined in the response schema.

These instructions let reviewers check source use, unsupported promises and routing. Broad qualities such as politeness can still matter, but they need a rubric and examples to be assessed consistently.

The application must enforce permissions. A model's decision to request a refund cannot authorise the refund, and a sentence in the system prompt cannot protect credentials supplied in context.

Use role prompts to establish perspective

A role prompt can set the intended audience and approach. “Explain this database error to a product manager who does not write SQL” is more specific than “Act as an expert.”

The role supplies communication context. It does not establish that the model has professional qualifications or knows private facts. Provide the relevant evidence and evaluate factual claims independently of the response's confident tone.

A useful test compares the role framed prompt with a plain task description. Keep the role if it improves the required output, such as readability for the intended audience.

Separate task planning from separate model calls

A prompt can ask a model to consider several steps within one response. A workflow can also split those steps across calls. These designs have different costs and failure modes.

For a support reply, a workflow might extract the order ID, retrieve the order, apply a cancellation rule in code and ask the model to draft the explanation. Each intermediate result can be checked before the next step.

That extra structure is useful when a step needs its own evidence, tool or validation. It also adds orchestration and possible latency. Three model calls do not have a fixed threefold cost because prompt lengths, output lengths, caching and parallel work all matter. See prompt chaining for choosing boundaries.

Use reasoning prompts where intermediate work helps

Chain of thought prompting demonstrated that worked reasoning examples could improve results on several benchmark tasks. A checkable calculation or explicit intermediate decision may also help in an application.

The benefit is model- and task dependent. Some classification tasks require reasoning; some arithmetic is better handled by a calculator. Models trained for reasoning may already perform internal steps without exposing them, so asking for a long explanation can add cost without improving the result.

Generated reasoning is not a dependable record of internal causation. Research on unfaithful chain of thought explanations found that explanations could omit influences on an answer. For review, retain source evidence, tool results and externally verifiable checks.

Self consistency and the limits of majority voting

Self consistency samples several solution paths and aggregates their final answers. The original paper reported improvements on selected reasoning benchmarks.

Suppose five runs produce final answers of 42, 42, 42, 41 and 43. Majority voting selects 42, with agreement of three out of five. That fraction describes the samples; it does not mean there is a 60% probability that 42 is correct.

The approach needs comparable final answers and useful diversity between runs. Five near identical attempts can repeat one error. Sampling settings may increase diversity, but the same missing evidence or misleading example can affect every attempt.

Additional attempts consume tokens. Parallel execution can reduce elapsed time but still uses capacity and may encounter rate limits. Measure the improvement against a single call baseline and an external verification step.

Choose a pattern by its failure mode

Keep a short record of why each instruction or example exists. When a prompt grows, remove one element at a time and rerun relevant cases. This turns prompt maintenance into an evidence based review rather than a collection of unexplained rules.