Principle:Diagram of thought Diagram of thought Prompt Template Selection
| Knowledge Sources | |
|---|---|
| Domains | Prompt_Engineering, Configuration |
| Last Updated | 2026-02-14 04:30 GMT |
Overview
Prompt Template Selection is the design decision of choosing an appropriate base prompt template that balances detail and conciseness for downstream customization of a structured reasoning system. This principle is library-agnostic and applies whenever a practitioner must decide which starting template to modify before deploying a Diagram of Thought (DoT) reasoning session.
Description
Template selection is a design decision with meaningful tradeoffs that directly affect how a DoT prompt can be customized for a target domain.
The Diagram of Thought repository provides two distinct template artifacts:
- Full template (
prompts/iterative-reasoner.md, 67 lines): Contains detailed role definitions with explicit objectives and behavioral instructions for each role (<proposer>,<critic>,<summarizer>), a step-by-step process flow, formatting guidelines, and a complete example interaction showing the expected XML tag alternation pattern. This template provides a large customization surface area -- every section (role descriptions, process flow, formatting rules, examples) can be independently modified, extended, or replaced. It is particularly helpful for less capable models or novel tasks where the model benefits from explicit behavioral guidance.
- Minimal template (
README.md:L63-97, 34 lines): A concise prompt that introduces the roles, includes the typed serialization protocol (@node,@edge,@statusrecords) inline, and provides a single worked structure showing role alternation with record interleaving. It omits detailed role descriptions and formatting guidelines, relying on the model's ability to generalize from the compact specification. This template is more token-efficient and better suited for highly capable models that can infer behavioral expectations from minimal instruction.
The choice between these templates affects several downstream concerns: the amount of context window consumed by the system prompt, the degree of behavioral constraint imposed on the model, the customization surface area available for domain-specific modifications, and the model's adherence to the intended reasoning protocol.
This principle is distinct from System Prompt Configuration, which concerns the act of loading a chosen prompt into an LLM session to initiate reasoning. Prompt Template Selection occurs before system prompt configuration -- it determines which template will be loaded and customized.
Usage
Prompt Template Selection is applied after defining task requirements and before customizing role instructions or other prompt content. It is specifically about choosing the starting template that will serve as the base for modification.
The decision process typically involves assessing:
- The target model's capability level (parameter count, instruction-following ability)
- The complexity and novelty of the target task
- The token budget available for the system prompt
- The degree of behavioral specificity required for the domain
Once a base template is selected, the practitioner proceeds to customize it (adjusting role instructions, adding domain-specific constraints, modifying examples, etc.) before loading the final prompt into the LLM session.
Theoretical Basis
Template selection relates to the concept of information density in prompt engineering. A prompt is a finite-length instruction that must encode sufficient behavioral constraints to guide model generation, while fitting within the model's context window alongside the actual reasoning content.
Longer prompts provide more behavioral constraints -- explicit role definitions, formatting rules, process flow descriptions, and worked examples all reduce ambiguity about expected behavior. However, they consume more of the context window, leaving less room for the reasoning trace itself. In tasks that require many iterations of the propose-critique-summarize cycle, a verbose system prompt can become a practical bottleneck.
Shorter prompts require the model to generalize from fewer examples and less explicit instruction. This is feasible when the model has strong instruction-following capabilities and the task pattern is not novel to the model. The minimal template's inclusion of typed records (@node, @edge, @status) alongside a compact role structure leverages the model's ability to infer the full behavioral protocol from a representative example.
This tradeoff is closely related to the few-shot vs. zero-shot learning distinction in prompt engineering. The full template functions as a few-shot prompt (providing an explicit example interaction), while the minimal template operates closer to a zero-shot or one-shot paradigm (providing a structural template without a complete worked example). Research in prompt engineering consistently shows that few-shot prompts improve performance on unfamiliar tasks, while capable models can match or exceed few-shot performance with well-structured zero-shot instructions on familiar task types.
The optimal choice thus depends on the interaction between model capability and task complexity. For a given model-task pair, there exists a threshold of prompt detail below which the model's reasoning quality degrades and above which additional detail yields diminishing returns while consuming valuable context window space.