Domain Prompt Templates

A prompt like "review this API design" gives the model maximum freedom in choosing what to evaluate and how deeply to examine each aspect. The model will apply its general knowledge of API design, which produces reasonable but surface-level feedback. This is where system prompts with embedded expertise make a measurable difference. It might comment on naming conventions and suggest pagination but will not systematically check HTTP method semantics, error response format compliance, rate limiting design, authentication placement, versioning strategy, or idempotency guarantees — unless the prompt specifically asks for these checks.

The gap between a generic prompt and an expert prompt mirrors the gap between asking a junior colleague "what do you think of this?" and handing them a detailed review checklist built from years of experience and past incidents. The checklist does not make the junior colleague an expert, but it ensures they evaluate against expert criteria and do not skip checks that an expert would perform automatically. Domain prompt templates do the same for AI models — they encode the expert's evaluation framework into a reusable format.

This matters more at scale. A single generic prompt produces a single generic review that a skilled human can supplement. But when a team runs dozens of reviews per week, the inconsistency of generic prompts — different aspects checked in each review, different depth of analysis — accumulates into unreliable quality. Templates provide the consistency that scales.

An effective template has four components. The role declaration sets the model's perspective and expertise level ("You are a senior security engineer conducting a pre-deployment review of a web application"). The evaluation criteria list the specific checks to perform, drawn from professional standards — OWASP for security reviews, WCAG for accessibility audits, REST conventions for API assessments, GAAP for financial analysis. The output format specifies how findings should be structured — severity levels, specific references to the reviewed material, remediation suggestions with effort estimates. And the context section explains what the model is evaluating and why, including relevant details about the project's technology stack, deployment environment, and constraints.

The criteria should be specific enough to be mechanically checkable. "Evaluate security" is too vague — the model must choose what to check and will likely choose different things each time. "Check every point where user input enters a database query. Verify parameterised queries are used. Flag any string concatenation in SQL construction. Check that ORM methods use parameter binding, not template literals." is actionable and reproducible. The model can follow this instruction mechanically and will catch issues that a vague prompt would miss.

Templates benefit from including both positive and negative examples of what they are looking for. Showing the model what a well-designed error response looks like alongside a poorly designed one teaches the evaluation standard more effectively than describing it abstractly. This mirrors the few-shot prompting technique of teaching by example. Two or three example pairs per major evaluation criterion significantly improve the template's effectiveness, drawing on the same principle that makes <a href="/aisapedia/few-shot-prompting">few-shot prompting</a> powerful.

Domain prompt templates are living documents, not write-once artefacts. Industry standards change (new OWASP top ten entries, updated accessibility guidelines, new regulatory requirements), and prompt versioning practices help track these updates systematically, team conventions evolve (new coding patterns, different deployment targets), and real-world use reveals gaps in the template's coverage (an issue type that keeps slipping through, a check that produces too many false positives). Teams that treat templates as immutable miss their primary advantage: they should improve with every use.

A practical maintenance approach mirrors <a href="/aisapedia/feedback-loop-design">feedback loop design</a>: after each use, note whether the template caught what it should have caught and whether it flagged issues that were not actually problems. Batch these observations into periodic template updates — monthly or quarterly, depending on how frequently the template is used. Version the templates so you can trace when specific checks were added, what motivated them, and whether they improved outcomes.

Store templates where the team can access and improve them collectively. A shared repository, a team wiki, or a set of <a href="/aisapedia/custom-gpts">Custom GPTs</a> all work as storage, as long as there is a clear process for proposing and reviewing template changes. A template maintained by one person tends to reflect that person's expertise and blind spots; a collaboratively maintained template draws on the collective experience of the team and produces more comprehensive coverage.

Templates become counterproductive when they are so prescriptive that the model spends all its context window and attention following the checklist rather than engaging with the substance of the material being reviewed. A template with 50 evaluation criteria will produce a mechanical checkbox exercise, not an insightful review. The model will dutifully check each criterion but will not synthesise findings or identify patterns that emerge across criteria — precisely the kind of high-level insight that makes expert reviews valuable.

The antidote is to distinguish between mandatory checks (things that must be evaluated every time, like input sanitisation in a security review) and contextual prompts (things the model should consider if relevant, like performance implications or maintainability). Mandatory checks are listed explicitly. Contextual prompts are framed as "also consider, where relevant" to give the model latitude to focus on what matters for the specific material being reviewed.

Periodically audit the template for check accumulation. Templates that grow by accretion — adding a new check every time something is missed — eventually become bloated with edge-case checks that add noise to routine reviews. Every few months, review all checks and remove those that address rare issues or that duplicate other checks. A shorter, sharper template typically outperforms a comprehensive but unwieldy one.

Another signal that a template has become counterproductive is when different team members start skipping checks or modifying the template locally rather than using it as written. This behaviour indicates that the template's requirements have outgrown its practical utility — the team has implicitly decided that some checks are not worth the effort. Use this feedback to simplify the template back to its essential checks, restoring compliance by reducing the burden rather than by enforcing the bloated version.