Prompt Templates

A saved prompt is static text that worked once for a specific input. A template is an architecture with clearly defined variable slots, fixed instructional scaffolding, and documented constraints that make it work reliably across diverse inputs. The difference is analogous to the difference between a single spreadsheet and a spreadsheet formula — one is a snapshot of one calculation, the other is a reusable computation that works with any numbers.

The power of a template lies in its fixed sections: the role definition that shapes the model's perspective, the output format specification that ensures structural consistency, the constraints that prevent known failure modes, and the analysis framework that structures the model's reasoning process. The variable slots — [COMPANY], [DATASET], [AUDIENCE] — are actually the smallest part of the template. The surrounding instructional context does the heavy lifting.

This distinction matters because it changes how you design them. When creating a template, the question is not 'what do I want the model to do with this specific input?' but 'what instructions, constraints, and frameworks will produce excellent output regardless of which input is provided?' The focus shifts from the content to the process.

Start with a prompt that produced excellent output for a single case, then identify which elements are task-specific (the variable parts) and which are quality-critical (the fixed parts) — similar to selecting few-shot examples. The fixed parts typically include: a role or persona definition, the analysis methodology or framework, output structure requirements, quality constraints, and instructions that prevent known failure modes.

Test the template with at least five meaningfully different inputs. Inputs that are too similar to the original will not reveal fragility. A template designed for analysing one type of company should be tested on companies of different sizes, industries, and maturity stages. Each test round usually reveals assumptions baked into the fixed text that only work for certain input types — these are the elements that need to be either generalised or converted into additional variable slots.

Document the template's boundaries explicitly. Every template has a range of inputs it handles well and edge cases where it degrades. Writing 'Best for: companies with public financial data. Degrades for: pre-revenue startups or private companies with limited public information' prevents misuse and saves debugging time. This documentation is what transforms a personal tool into a team asset suitable for inclusion in /aisapedia/prompt-libraries.

Include an example of expected output alongside the template itself. Models follow demonstrated patterns more reliably than described patterns, and team members evaluating whether a template fits their need can quickly assess quality from a concrete example rather than trying to imagine what the output will look like from the instructions alone.

The role-context-task-format (RCTF) structure is the most widely used and easiest to design. Role sets the model's perspective and expertise level ('Acting as a senior financial analyst with ten years of experience in emerging markets'). Context provides the variable background, and negative constraints specify what to avoid ('[MARKET CONDITIONS], [COMPANY PROFILE]'). Task specifies the operation ('Evaluate the investment opportunity against these four criteria'). Format defines the output structure ('Three supporting points, two risk factors, and a final recommendation with confidence level'). Each section can be tuned independently without affecting the others.

The criteria-matrix structure works well for evaluation and comparison tasks. It defines a fixed set of evaluation criteria with scoring guidelines, followed by the variable item to evaluate. This produces consistent, comparable assessments across different inputs — useful for vendor evaluations, content quality audits, candidate reviews, or any task where you need to apply the same standard to multiple items.

The progressive-disclosure structure starts with a broad analysis and drills down based on initial findings. 'First, summarise the three key themes in [INPUT]. Then, for the highest-priority theme, provide detailed analysis including root causes and implications. Finally, recommend three specific actions for the most critical finding.' This mirrors how an experienced analyst would approach the work and prevents the model from getting lost in details before establishing the big picture.

Choosing the right structure depends on the task type. RCTF works for most analytical and generative tasks. Criteria-matrix works for evaluative tasks. Progressive-disclosure works for tasks where the analysis path depends on what the initial findings reveal. Using /aisapedia/meta-prompting to generate initial template structures can accelerate the design process.

The most common failure mode is input drift — the template was designed for one type of input, but over time team members start feeding it inputs that fall outside its design range — a subtle form of prompt failure. A template built for analysing public companies degrades silently when applied to early-stage startups with no financial data. Clear boundary documentation, as described above, is the primary defence against input drift.

Model version changes can also break templates. When a provider updates a model, the same template text may be interpreted differently, producing outputs that diverge from established quality standards. Tagging each template with the model version it was validated against and re-testing after updates prevents this type of silent degradation.

Maintaining templates requires periodic review based on actual usage data. Templates that team members consistently modify before using — adding or removing constraints, changing the output format, rewording the role definition — are signalling that the canonical version no longer fits the team's needs. These ad-hoc modifications should be captured and incorporated into the template itself to prevent each user from independently solving the same problem.

Templates that serve multiple output consumers — where the result is used by different teams, tools, or processes — should include explicit output format specifications that satisfy all consumers. A competitive analysis template whose output feeds both a presentation deck and a database import needs to produce structured data that can serve both purposes, or include instructions to generate both formats in a single response. Designing for downstream consumption upfront prevents the reformatting work that undermines the template's efficiency promise.