Domain-Specific Few-Shot Example Generator Prompt Template

Domain experts and AI engineers use this prompt to bootstrap a library of few-shot examples from scratch when generic examples fail to capture domain terminology, regulatory constraints, or risk patterns. The core job-to-be-done is translating a domain specification, a task description, and a set of constraints into input-output demonstration pairs that teach a model the desired behavior. This is not a prompt for formatting existing examples or converting instruction-heavy prompts into demonstrations—use the Example-to-Instruction Conversion Prompt for those workflows. The ideal user is someone who understands the domain deeply enough to validate the generated examples but needs a structured starting point to avoid blank-page paralysis when building a new example library.

Use this prompt when you are entering a specialized domain—such as medical coding, legal review, or financial compliance—where off-the-shelf few-shot examples would miss critical terminology, misclassify risk, or violate regulatory boundaries. It is also appropriate when you need to establish a consistent demonstration format across a team before scaling example creation. Do not use this prompt when you already have a validated example library and only need to adapt formatting for a different model; that work belongs to the Model-Specific Prompt Migration playbook. Similarly, avoid this prompt when your primary need is to detect drift in an existing example set—the Example Drift Detection Prompt handles staleness and distribution shift. The generator is a creation tool, not a maintenance or migration tool.

Before running this prompt, prepare three inputs: a clear domain specification defining the terminology, entities, and constraints that make the domain unique; a task description that scopes what the model should produce (extraction, classification, summarization, refusal); and a set of constraints that encode regulatory, safety, or format requirements. The prompt will produce demonstration pairs, but you must validate them against your domain knowledge before they enter production. Treat the output as a first draft that requires expert review, especially in high-risk domains where incorrect examples can teach dangerous behaviors. After validation, feed the approved examples into your prompt assembly and wire them into your evaluation harness using the Example Validation and Quality Assurance playbook.

The following prompt template is designed to generate high-quality, domain-specific input-output demonstration pairs. It guides the model to act as a domain expert and produce examples that capture the terminology, constraints, and risk patterns unique to your field. Before using this template, you must prepare your specific domain context, the exact output schema you require, and a clear set of constraints that define what a correct example looks like. This prompt is not a one-shot solution; it is a structured request that should be iterated on and its output rigorously validated.

codeCopy
You are a senior domain expert in [DOMAIN, e.g., medical coding, legal contract review, financial compliance]. Your task is to generate a set of high-quality, realistic few-shot examples that will be used to teach another AI model how to perform the task of [TASK_DESCRIPTION].

Each example must be a valid input-output pair that strictly adheres to the following rules:

1.  **Domain Accuracy:** All terminology, entities, and logic must be factually and contextually correct for the [DOMAIN] field.
2.  **Constraint Adherence:** The output must strictly follow all provided constraints: [CONSTRAINTS, e.g., 'never infer a diagnosis from symptoms alone', 'always cite the specific clause', 'flag transactions above $10,000'].
3.  **Output Schema:** The output must be a valid JSON object conforming to this schema: [OUTPUT_SCHEMA].
4.  **Risk Pattern Coverage:** Examples should cover common edge cases and risk patterns, such as [RISK_PATTERNS, e.g., 'ambiguous abbreviations', 'conflicting clauses', 'structuring transactions'].
5.  **Diversity:** Generate [NUMBER] examples that vary in complexity and scenario, including at least one simple case, one complex case, and one edge case that tests a boundary condition.

Here is the specific context and background information you must use:
[CONTEXT]

Generate the examples now. The output must be a single JSON array of objects, where each object has an "input" and an "output" field.

To adapt this template, replace each square-bracket placeholder with your specific requirements. The [OUTPUT_SCHEMA] should be a valid JSON schema definition. The [CONSTRAINTS] are the critical business rules that must never be violated. The [RISK_PATTERNS] are the specific failure modes you are trying to prevent. After generating the examples, you must run them through a validation harness that checks for schema compliance, constraint violations, and domain accuracy. For high-risk domains, a human expert must review and approve the generated example library before it is used in any production system. Never use generated examples without this validation step, as a single flawed example can teach the model a dangerous or incorrect behavior pattern.

This prompt is not a one-off playground exercise. It is a data-generation pipeline component that produces training and evaluation artifacts for domain-specific AI systems. The implementation harness must treat the prompt as a deterministic function: given a domain specification and constraints, it returns a set of validated input-output demonstration pairs. The harness is responsible for enforcing schema compliance, running domain-specific validation checks, and logging every generation for auditability. Because the output becomes part of a downstream example library that may influence model behavior in regulated domains, the harness must include human review gates before any generated examples are committed to production use.

Wire the prompt into an application by first constructing a strict input payload. Required fields include [DOMAIN], [TASK_TYPE] (e.g., extraction, classification, summarization), [CONSTRAINTS] (regulatory rules, terminology standards, risk boundaries), [OUTPUT_SCHEMA] (the exact JSON schema for each example pair), and [NUM_EXAMPLES]. The application layer should validate this input payload before calling the model. After receiving the model response, run structural validation to confirm the output is valid JSON matching the requested schema. Then run domain-specific semantic checks: for medical examples, verify SNOMED/ICD code validity against a reference database; for legal examples, check that generated citations follow Bluebook format and that no fabricated case names appear; for financial examples, confirm numeric precision matches regulatory requirements (e.g., SEC filing decimal places). Any example that fails these checks should be flagged for repair or rejection, not silently included in the library.

Implement a retry-and-escalation loop. If the model produces malformed JSON or fewer examples than requested, retry with the same prompt up to two times. If structural validation still fails, log the failure and escalate to a human reviewer with the raw output attached. For semantic validation failures, do not retry automatically—domain errors often indicate a misunderstanding that retries will not fix. Instead, route the failed examples to a review queue where a domain expert can correct or reject them. Log every generation attempt with a unique generation_id, the model version used, the prompt template version, the input parameters, the raw output, validation results, and the final disposition (accepted, corrected, rejected). This audit trail is essential for governance in regulated workflows and for debugging example drift over time.

Choose your model based on the domain's risk level and complexity. For high-stakes medical, legal, or financial example generation, use a frontier model with strong instruction-following and low hallucination rates (e.g., GPT-4, Claude 3.5 Sonnet). For lower-risk technical documentation or internal tooling examples, a smaller, faster model may suffice. Set temperature to 0 or very low (0.1–0.2) to maximize determinism and reproducibility—this is a data curation task, not a creative one. If your domain requires examples that span multiple difficulty levels or edge cases, consider running the prompt multiple times with different [CONSTRAINTS] blocks (e.g., "standard cases only" vs. "edge cases with conflicting constraints") and merging the results. Always version your prompt template and your generated example library together so you can trace which prompt version produced which examples.

Before integrating generated examples into a production system, run an evaluation harness that tests the examples against the target model you intend to use downstream. Feed the generated few-shot examples into the downstream prompt and measure whether the model's behavior matches the intended pattern. If the examples cause over-refusal, format drift, or unexpected outputs, they need revision. This closes the loop: the generator prompt produces examples, the validation harness checks them, the human reviewer approves them, and the evaluation harness confirms they actually work. Do not skip the evaluation step—examples that look correct on inspection can still produce surprising model behavior when used in context.