Few-Shot Example Expansion Prompt from Single Seed

This prompt is designed for the data preparation stage, not the runtime inference path. Use it when you have a single, high-quality input-output example that perfectly captures a desired task pattern but need a diverse few-shot set to stabilize model behavior in production. The ideal user is an ML engineer or prompt designer who understands the target task deeply enough to validate generated variations and who faces a scaling problem: manual example creation is too slow, too expensive, or too narrow to cover the range of inputs the system will encounter in production. You should have a clear output schema, a defined task boundary, and a way to programmatically or manually review the generated examples before they ship in a prompt.

This prompt works best when the seed example is structurally representative of the task but limited in surface diversity—same entities, same register, same complexity level. The expansion prompt generates variations across entities, style, register, and complexity while preserving the underlying task pattern. It is particularly effective for bootstrapping few-shot prompts for classification, extraction, structured output generation, and tool-use demonstrations where example diversity directly reduces brittle behavior. You can also use it to build evaluation suites that require coverage across difficulty levels and input types, or to generate training data for fine-tuning when you need to scale from a small set of validated examples. The prompt includes diversity metric checks and token budget awareness, so you can control how many examples you generate and how different they are from the seed.

Do not use this prompt when the seed example itself is ambiguous, incorrect, or unrepresentative of the task—garbage in, garbage out applies with full force here. Do not use it for tasks where the model must learn entirely new reasoning patterns from scratch; this prompt varies surface features, not deep task structure. Do not use it in the runtime inference path; this is an offline data preparation tool. Avoid relying on generated examples without human review or automated validation, especially in high-risk domains like healthcare, finance, or legal applications where incorrect examples can teach the model dangerous behaviors. If your task requires domain-specific terminology, regulatory constraints, or safety boundaries, pair this prompt with domain-expert review and consider using the sibling prompts for counterexample generation, edge-case sampling, and fairness attribute swapping to ensure the expanded set doesn't introduce new failure modes.

This prompt template takes a single seed example—one input and its corresponding ideal output—and instructs the model to generate a set of variations. The goal is to produce a diverse few-shot example set that covers different entities, styles, registers, and complexity levels. This is useful when you have a clear pattern but limited initial data, and you need to quickly bootstrap a training or evaluation set for a prompt-driven system.

textCopy
You are an expert example-generation assistant. Your task is to expand a single seed example into a diverse set of few-shot examples for training or evaluating an AI system.

## SEED EXAMPLE
Input:
[SEED_INPUT]

Output:
[SEED_OUTPUT]

## GENERATION INSTRUCTIONS
Generate exactly [NUM_EXAMPLES] new examples. Each example must consist of an "input" and an "output" that follow the same underlying pattern and task structure as the seed example.

Apply the following variation strategies, distributing them across the generated set:
1. **Entity Substitution:** Replace named entities (people, organizations, locations, dates, products) with different but realistic alternatives of the same type.
2. **Register Shift:** Vary the formality and style. Create versions in casual, professional, and technical registers.
3. **Complexity Scaling:** Create simpler versions (shorter, more direct) and more complex versions (longer, with more constraints or nuanced requirements).
4. **Lexical Variation:** Use synonyms and different phrasing while preserving the exact intent.

## CONSTRAINTS
- Preserve the core task and output structure of the seed example exactly.
- Do not introduce new tasks or change the fundamental relationship between input and output.
- Ensure all generated outputs are factually consistent with their inputs.
- If the seed output follows a specific format (JSON, XML, list, etc.), all generated outputs must conform to that same format.
- Avoid generating examples that are trivial, nonsensical, or violate common sense.
- [ADDITIONAL_CONSTRAINTS]

## OUTPUT FORMAT
Return a single JSON object with a key "examples" containing an array of objects, each with "input" and "output" fields.

## DIVERSITY CHECK
Before finalizing, review the generated set and ensure:
- At least [MIN_ENTITY_VARIATIONS] distinct entities have been introduced.
- At least [MIN_REGISTER_VARIATIONS] distinct registers are represented.
- The examples span a range of complexity from simple to challenging.

To adapt this template, replace the square-bracket placeholders with your specific values. [SEED_INPUT] and [SEED_OUTPUT] are your single starting example. [NUM_EXAMPLES] controls the size of the generated set; start with 5-10 for initial testing. [ADDITIONAL_CONSTRAINTS] is where you can inject domain-specific rules, such as 'All dates must be in ISO 8601 format' or 'Do not use any real patient data.' The diversity check parameters ([MIN_ENTITY_VARIATIONS], [MIN_REGISTER_VARIATIONS]) let you enforce minimum coverage requirements. After generating the set, always run a validation step to confirm that every output conforms to your expected schema and that no examples have drifted from the original task intent.

The Few-Shot Example Expansion Prompt is not a one-off playground utility; it is a data generation step that should be integrated into a repeatable pipeline. The prompt takes a single seed input-output pair and produces multiple diverse variants, which means the harness must manage input validation, output parsing, token budget enforcement, and downstream quality checks before any generated example enters a training or evaluation dataset. Treat this prompt as a batch processor: you will typically call it many times across different seeds, and each call must be independently verifiable.

The implementation harness should wrap the LLM call with pre-flight and post-flight checks. Before calling the model, validate that the seed example matches the expected schema—if the seed is malformed, expansion will amplify the error. After receiving the model response, parse the output into a structured list of examples and run each through a validator that checks for schema compliance, semantic drift from the original intent, and diversity metrics such as entity variation and syntactic distance. A common failure mode is the model producing near-duplicate variants; implement a deduplication step using embedding cosine similarity or token-level Jaccard distance with a threshold of 0.85 or higher. For high-stakes datasets, route a sample of generated examples to human review before they are committed to the example store.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Set temperature between 0.7 and 0.9 to encourage variation, but pin top_p to 0.95 to avoid degenerate outputs. Implement a retry loop with exponential backoff: if the output fails schema validation or produces fewer than the requested number of valid variants, retry up to three times with a modified prompt that includes the validation error as feedback. Log every call—seed input, generated variants, validation results, retry count, and token usage—so that drift in generation quality can be traced over time. Finally, never let generated examples flow directly into a production prompt without passing through a regression test suite that compares model behavior on the original seed versus the expanded set.