Skip to content

PATTERN Cited by 1 source

Prompt template library

Intent

Ship a centralised library of per-application prompt templates — complete with few-shot exemplars, default parameter settings, and style characteristics pre-baked — that callers pick from a menu rather than writing prompts from scratch.

Templates are defaults with editable overrides, not constraints. Callers inherit working baselines immediately and retain full control to override per-project.

Why a library, not per-caller prompts

  • Onboarding cost. Without templates, every new team walks the prompt-engineering learning curve alone. With templates, a team picks an application and ships a working prompt on day one.
  • Style consistency. All images for a given application share the template's lighting / background / framing. No per-team drift.
  • Platform-team iteration leverage. When a better template lands (new few-shot exemplars, better wording), all callers pick it up at once.
  • Platform-team quality investment. Central curation means the templates reflect the platform team's accumulated knowledge of what works — knowledge that isn't replicable in every caller team's ramp-up.

Archetype

From Instacart PIXEL (Source: sources/2025-07-17-instacart-introducing-pixel-instacarts-unified-image-generation-platform):

"It provides access to a variety of models, generates the right parameters and configurations, and has strong defaults for prompts for both generating and evaluating images with the added ability for teams to modify those defaults as needed."

"Once a model is chosen, team members can leverage a number of prompt templates to maintain consistency. These prompt templates define characteristics about lighting, backgrounds, and the image context are injected as few shot examples for each application. Teams can follow practical guidelines to create effective prompts across different models, reducing trial and error in the process."

Structure of a template

A typical image-generation template carries:

  • Prompt scaffold — natural-language template with slots for per-request content (<product>, <retailer>, <scene>).
  • Few-shot exemplars — example images the template injects as few-shot conditioning to define target style.
  • Style characteristics — lighting, background, framing, camera angle as named knobs.
  • Parameter defaults — style, size, cfg_scale under the unified parameter protocol.
  • Evaluation rubric — project-specific evaluation questions the VLM judge uses to score output.
  • Override hooks — documented extension points where teams can override defaults without forking the template.

Tradeoffs / gotchas

  • Template sprawl. One-template-per-application grows unboundedly as the platform absorbs new use cases. Template discovery, deprecation, and consolidation become operational work.
  • Default drift. If templates aren't versioned, callers who depend on a specific style can silently break when templates update.
  • Override escape valve matters. A template that teams can't override gets forked informally — callers start prompt-engineering around the template's fixed parts. Keep overrides easy.
  • Evaluation rubric coupling. A template's evaluation questions must be kept in sync with the prompt — a changed prompt shape can make old questions irrelevant and vice versa.

Relationship to sibling patterns

  • patterns/instruction-library-prompt-composition — the Dropbox Dash-judge DSPy pattern where the library carries instruction bullets rather than whole templates, and an optimiser selects + composes bullets rather than picking one template. Constrained-sibling pattern — applicable when total prompt rewrite is too risky for a production-critical judge.
  • concepts/few-shot-prompt-template — the underlying primitive a prompt-template library is built from.

Seen in

Last updated · 319 distilled / 1,201 read