Cross-Model Prompt Translation Template

Use the Cross-Model Prompt Translation Template when you are migrating a working prompt from one model family to another and need to preserve behavioral equivalence rather than just copy-paste the text. The primary job-to-be-done is translating prompt structure, formatting conventions, and instruction patterns between OpenAI, Claude, Gemini, and open-weight models so that the target model produces outputs that match the source model's behavior on the same inputs. The ideal user is an engineering lead or AI builder who already has a validated prompt running in production on one model and now needs to ship it on a different model without silently breaking downstream consumers.

This template is not for initial prompt authoring, model selection, or performance benchmarking. Do not use it when you are writing a prompt from scratch, comparing models for the first time, or optimizing for cost and latency independently of behavioral fidelity. The template assumes you already have a stable source prompt with known good outputs, a set of representative test inputs, and a clear definition of what equivalence means for your use case—whether that is exact output structure, semantic similarity, tool-call accuracy, or refusal boundary alignment. Without those prerequisites, translation becomes guesswork rather than engineering.

Before applying this template, gather your source prompt, a golden dataset of at least 10–20 input-output pairs from the source model, and your equivalence criteria. The template will guide you through structural translation (system message placement, role tagging, formatting conventions), instruction adaptation (model-specific phrasing, constraint encoding), and regression testing. If your workflow involves regulated outputs, safety-critical decisions, or user-facing content where subtle behavioral drift could cause harm, plan for human review of translated outputs before deployment. The next section provides the copy-ready template you will adapt for your specific migration.

The template below is designed to be copied directly into your prompt assembly pipeline. It accepts a source prompt written for one model family and a target model specification, then produces a translated prompt that respects the target model's formatting conventions, instruction patterns, and behavioral quirks. Every square-bracket placeholder must be resolved before inference. The template includes explicit instructions for preserving output schema, handling unsupported features, and flagging untranslatable constraints.

codeCopy
You are a prompt translation engine. Your job is to translate a source prompt written for [SOURCE_MODEL_FAMILY] into a functionally equivalent prompt for [TARGET_MODEL_FAMILY]. Preserve the original intent, output structure, constraints, and behavioral expectations. Do not add, remove, or reinterpret requirements unless forced by the target model's limitations.

## SOURCE PROMPT
[SOURCE_PROMPT]

## TARGET MODEL SPECIFICATION
- Model family: [TARGET_MODEL_FAMILY]
- Model identifier: [TARGET_MODEL_ID]
- Context window: [TARGET_CONTEXT_WINDOW]
- Supported features: [TARGET_SUPPORTED_FEATURES]
- Formatting conventions: [TARGET_FORMATTING_CONVENTIONS]
- Known behavioral differences: [TARGET_BEHAVIORAL_DIFFERENCES]

## TRANSLATION RULES
1. Reformat instructions to match [TARGET_MODEL_FAMILY] conventions. If the target model prefers XML tags, wrap sections in <instruction>, <context>, <examples>, <output_format>. If it prefers markdown headers, use ## headers. If it prefers flat text with clear delimiters, use --- separators.
2. Preserve the original output schema exactly: [OUTPUT_SCHEMA]. If the target model cannot reliably produce this schema, add explicit formatting instructions and note the risk in a [UNSUPPORTED_FEATURES] block.
3. Map system-level instructions to the target model's equivalent. If the target model has no system message concept, merge system instructions into the user message with clear role labeling.
4. Convert few-shot examples to the target model's preferred format. If the target model responds better to XML-wrapped examples, restructure accordingly.
5. Handle tool definitions: [TOOLS]. If the target model uses a different tool-calling format, convert the schema. If tool calling is unsupported, convert tools to text-based function descriptions with explicit output format instructions.
6. Adjust for context window: if the translated prompt exceeds [TARGET_CONTEXT_WINDOW] tokens, apply ranked truncation: (a) trim low-priority examples first, (b) compress verbose instructions, (c) summarize long context blocks. Never drop [CONSTRAINTS] or [OUTPUT_SCHEMA].
7. Flag untranslatable elements: if any instruction, constraint, or feature cannot be faithfully translated, add an [UNTRANSLATABLE] section at the end of the output explaining what was lost and why.

## OUTPUT FORMAT
Produce a JSON object with these fields:
{
  "translated_prompt": "<the full translated prompt as a string>",
  "translation_notes": ["<list of specific changes made and why>"],
  "untranslatable_elements": ["<list of elements that could not be faithfully translated>"],
  "risk_assessment": "<LOW|MEDIUM|HIGH> risk of behavioral divergence",
  "token_estimate": <estimated token count of translated prompt>,
  "regression_test_suggestions": ["<list of test cases to verify behavioral equivalence>"]
}

## CONSTRAINTS
- Do not hallucinate features the target model does not support.
- If [RISK_LEVEL] is HIGH, include explicit human review instructions in the translated prompt.
- Preserve all [CONSTRAINTS] from the source prompt unless the target model fundamentally cannot enforce them.
- If the source prompt includes PII handling rules, redaction instructions, or safety policies, these must survive translation intact.

To adapt this template for your pipeline, replace each placeholder with runtime values. [SOURCE_MODEL_FAMILY] and [TARGET_MODEL_FAMILY] should use consistent identifiers like openai, claude, gemini, or llama. [TARGET_FORMATTING_CONVENTIONS] should describe the target model's known preferences, such as 'prefers XML-wrapped sections', 'responds best to markdown headers', or 'requires flat text with explicit delimiters'. [TARGET_BEHAVIORAL_DIFFERENCES] should capture known quirks, such as 'ignores trailing instructions', 'over-indexes on early examples', or 'struggles with nested JSON'. [TARGET_SUPPORTED_FEATURES] should list capabilities like system_message, function_calling, json_mode, or streaming. The [RISK_LEVEL] placeholder should be set to LOW, MEDIUM, or HIGH based on the criticality of the workflow. For high-risk domains such as healthcare, legal, or finance, always set [RISK_LEVEL] to HIGH and ensure the translated prompt includes explicit human review gates. After translation, run the suggested regression tests against both the source and target models to verify behavioral equivalence before shipping.

This prompt template is designed to be integrated into a structured translation pipeline, not used as a one-off chat. The core workflow involves: (1) accepting a source prompt and its origin model family, (2) accepting a target model family, (3) assembling the translation prompt with these inputs, (4) calling the translator model, and (5) validating the translated prompt's structure and behavioral equivalence before deployment. The harness should treat the translation as a code change—requiring version control, regression tests, and a review gate before the translated prompt reaches production traffic.

Implement the harness as a function or service with a clear interface: translate_prompt(source_prompt: str, source_model: str, target_model: str, behavioral_tests: list[str]) -> TranslatedPrompt. Internally, the function should: validate that source_model and target_model are recognized model families (e.g., openai, claude, gemini, llama); inject the source prompt, model identifiers, and behavioral test cases into the [SOURCE_PROMPT], [SOURCE_MODEL], [TARGET_MODEL], and [BEHAVIORAL_TESTS] placeholders; call the translator model with a low temperature (0.0–0.2) for deterministic output; parse the response to extract the translated prompt from the designated output block; and run the translated prompt against the provided behavioral test cases using a separate evaluation model or deterministic checks. Log the full translation request, response, and test results with a unique translation_id for traceability. If any behavioral test fails, the harness should either retry with a revised translation request that includes the failure details or flag the translation for human review.

For production use, add a human-in-the-loop approval step before the translated prompt replaces an existing prompt in a live system. Store the translated prompt in a prompt registry with metadata: source prompt version, translator model used, translation timestamp, behavioral test pass/fail results, and reviewer identity. When migrating prompts across major model version boundaries (e.g., GPT-4 to GPT-4o, Claude 3 to Claude 4), run the full behavioral test suite and compare output distributions, not just pass/fail on a handful of examples. Avoid treating the translated prompt as finished until it has been evaluated on real or representative production inputs in a shadow or canary deployment.