Model-Specific Adaptation via Examples Prompt

This prompt is for engineering teams migrating a working prompt from one model family to another when the target model produces different output quality, format, or reasoning patterns. Instead of rewriting instructions from scratch, you provide paired examples of the source model's behavior and the desired target model behavior. The prompt teaches the target model to adapt its responses by demonstrating the differences. Use this when you have a stable prompt on Model A and need equivalent behavior on Model B, but instruction-only migration has failed.

The ideal user is a developer or AI engineer who has already attempted a direct instruction port and observed specific, reproducible failure modes: the target model hallucinates fields, skips reasoning steps, uses the wrong output schema, or applies different judgment criteria. You must have access to a set of representative inputs and the corresponding correct outputs from both the source model and your desired target behavior. Without these paired examples, this prompt cannot function. The examples must capture the specific behavioral gap—not just generic input-output pairs. For instance, if the target model refuses requests the source model handled, your examples must demonstrate the correct refusal boundary. If the target model produces verbose reasoning when conciseness is required, your examples must show the compressed reasoning pattern.

Do not use this prompt for initial prompt design or for models within the same family where behavior is already consistent. It is not a substitute for proper instruction engineering when you are starting from scratch. Avoid this approach when the behavioral gap is too large to bridge with a handful of examples—if the target model fundamentally lacks a capability the source model possessed, no amount of demonstration will close that gap. In such cases, you may need to redesign the workflow, add tool support, or accept a different output contract. For high-risk domains such as healthcare, legal, or finance, always pair this prompt with regression tests that compare target model outputs against a golden dataset, and require human review before production deployment.

This prompt template is designed to migrate a prompt's behavior from one model family to another. Instead of writing abstract instructions about how the target model should behave, you provide concrete examples of the source model's output and the desired target model's output for the same inputs. This few-shot demonstration approach is often more effective than instruction-only prompts when adapting to models with different reasoning styles, formatting preferences, or verbosity defaults.

textCopy
You are a prompt adaptation engine. Your task is to learn a behavioral transformation from the provided examples and apply it to new inputs.

# Transformation Goal
Convert outputs that follow the [SOURCE_MODEL_FAMILY] style into outputs that follow the [TARGET_MODEL_FAMILY] style, while preserving the core factual content and task completion.

# Target Model Behavioral Contract
- Reasoning style: [REASONING_STYLE, e.g., 'explicit chain-of-thought before conclusion', 'concise direct answer']
- Formatting: [FORMATTING_RULES, e.g., 'use markdown headings for sections', 'return only raw JSON without markdown fences']
- Verbosity: [VERBOSITY_LEVEL, e.g., 'brief, under 100 words', 'comprehensive with examples']
- Constraints: [CONSTRAINTS, e.g., 'never use first-person pronouns', 'always cite sources with brackets [1]']

# Adaptation Examples
## Example 1
### Source Output ([SOURCE_MODEL_FAMILY])
[SOURCE_OUTPUT_1]

### Target Output ([TARGET_MODEL_FAMILY])
[TARGET_OUTPUT_1]

## Example 2
### Source Output ([SOURCE_MODEL_FAMILY])
[SOURCE_OUTPUT_2]

### Target Output ([TARGET_MODEL_FAMILY])
[TARGET_OUTPUT_2]

# New Input for Adaptation
Transform the following [SOURCE_MODEL_FAMILY]-style output into the [TARGET_MODEL_FAMILY] style:

[INPUT_TO_ADAPT]

# Your Adapted Output

To use this template effectively, select 2-3 examples that showcase the most critical behavioral differences between the source and target models. Focus on examples where the source model's output violates the target model's expected contract—for instance, a source output that is too verbose, uses the wrong format, or lacks required reasoning steps. The target output in each example should be a manually crafted or reviewed ideal response. After running the prompt, validate the adapted output against your target model's specific requirements using automated schema checks, format validators, and a regression test suite that compares key quality metrics across models. For high-risk domains, always include a human review step before deploying adapted prompts to production.

This prompt is designed to be the central engine in a prompt migration pipeline, not a one-off copy-paste task. The harness should accept a source prompt, a set of example input-output pairs that demonstrate the desired behavior on the target model, and a target model identifier. The prompt's output is a candidate adapted prompt. Before that candidate reaches production, the harness must validate it against a pre-built regression suite of known inputs and expected outputs on the target model. Treat the adapted prompt as a pull request that requires passing tests before merge.

Implement the harness as a script or microservice with clear stages: (1) Assemble the adaptation request by injecting the source prompt, the behavior-demonstration examples, and the target model name into the prompt template's [SOURCE_PROMPT], [BEHAVIOR_EXAMPLES], and [TARGET_MODEL] placeholders. (2) Call the adaptation model (often a capable frontier model like GPT-4o or Claude 3.5 Sonnet) with temperature=0 for deterministic output. (3) Parse the output to extract the adapted prompt from the adapted_prompt field in the JSON response. If parsing fails, retry once with a stronger format reminder appended to the request. (4) Execute the regression suite by running the original source prompt on the source model and the adapted prompt on the target model against a golden dataset of at least 20 diverse inputs. Compare outputs using a combination of structural schema validation, key fact assertion checks, and an LLM-as-judge rubric that scores semantic equivalence on a 1-5 scale. Flag any adapted prompt where the average score drops below 4.0 or where any individual test case fails a critical safety or accuracy assertion.

Log every adaptation run with the source prompt hash, example set version, target model, adapted prompt, and regression scores. This audit trail is essential for debugging when a migration degrades behavior weeks later. For high-risk domains, insert a human review gate before the adapted prompt is deployed: surface the regression report, highlight score drops and specific failure cases, and require explicit approval. Avoid the temptation to auto-apply adaptations without regression testing; model-specific quirks often produce subtle failures in edge cases that only systematic evaluation catches. Start with a small canary deployment (5% of traffic) and monitor production eval metrics for 24 hours before full rollout.