Prompt Version Migration Compatibility Assessment Prompt

Use this prompt when you are a platform engineer or release manager responsible for approving a candidate prompt version that must replace a production prompt across multiple active workflows, model targets, or user segments. The primary job-to-be-done is generating a structured, evidence-based migration-readiness report that identifies blocking issues, breaking changes, and a recommended rollout strategy before any deployment occurs. This prompt is designed for formal release gate processes where prompts are treated as versioned artifacts with documented compatibility requirements, not for ad-hoc wording tweaks.

You must have access to the complete text of the old prompt, the complete text of the new prompt, a list of active workflows that consume the prompt, the target model identifiers (e.g., gpt-4o, claude-sonnet-4-20250514), and any known golden test cases or regression datasets. The prompt assumes you can provide these inputs as structured data. The output is a migration-readiness report that includes a compatibility matrix, a list of blocking issues, a canary-test pass/fail criteria set, and a recommended rollout strategy (e.g., full cutover, canary by traffic percentage, or workflow-by-workflow migration).

Do not use this prompt for trivial wording changes where a simple diff review and a single regression test run would suffice. It is overkill for single-workflow, single-model deployments with no downstream consumers. If your change is limited to fixing a typo, adjusting a single few-shot example, or updating a non-functional comment, skip this assessment and rely on your standard CI/CD prompt evaluation gates. This prompt is also inappropriate for initial prompt authoring; it is strictly for migration compatibility assessment between two existing versions. After running this assessment, use the report to decide whether to proceed, roll back, or request modifications before resubmitting for approval.

The following prompt template is designed to be dropped into your evaluation harness or used directly with a frontier model to produce a structured migration-readiness report. It expects you to supply the old prompt, the new prompt, and a description of the production environment where the prompt operates. The output is a JSON report containing blocking issues, warnings, a recommended rollout strategy, and explicit canary-test pass/fail criteria. This template is the core artifact you will version-control alongside your prompt library.

textCopy
You are a prompt migration assessor. Your task is to compare an OLD_PROMPT and a NEW_PROMPT and determine whether the new version can safely replace the old one across all active workflows, model targets, and user segments.

## INPUTS

OLD_PROMPT:
[OLD_PROMPT]

NEW_PROMPT:
[NEW_PROMPT]

PRODUCTION_CONTEXT:
[PRODUCTION_CONTEXT]

MODEL_TARGETS:
[MODEL_TARGETS]

ACTIVE_WORKFLOWS:
[ACTIVE_WORKFLOWS]

USER_SEGMENTS:
[USER_SEGMENTS]

KNOWN_FAILURE_MODES:
[KNOWN_FAILURE_MODES]

REGRESSION_TEST_RESULTS:
[REGRESSION_TEST_RESULTS]

## OUTPUT_SCHEMA

Return a JSON object with the following structure:
{
  "migration_verdict": "SAFE_TO_PROCEED" | "PROCEED_WITH_CAUTION" | "BLOCKED",
  "blocking_issues": [
    {
      "severity": "BLOCKER",
      "category": "SCHEMA_BREAKING_CHANGE" | "SAFETY_BOUNDARY_SHIFT" | "INSTRUCTION_CONFLICT" | "TOOL_CONTRACT_BREAK" | "CLASSIFICATION_DRIFT" | "CITATION_DEGRADATION" | "OTHER",
      "description": "string",
      "affected_workflows": ["string"],
      "evidence": "string"
    }
  ],
  "warnings": [
    {
      "severity": "WARNING",
      "category": "SEMANTIC_DRIFT" | "OUTPUT_STYLE_CHANGE" | "LATENCY_INCREASE" | "TOKEN_COST_INCREASE" | "REFUSAL_RATE_CHANGE" | "OTHER",
      "description": "string",
      "affected_workflows": ["string"],
      "mitigation": "string"
    }
  ],
  "rollout_strategy": {
    "recommended_approach": "DIRECT_DEPLOY" | "CANARY_DEPLOY" | "SHADOW_DEPLOY" | "STAGED_ROLLOUT",
    "canary_configuration": {
      "traffic_percentage": number,
      "duration_hours": number,
      "target_segments": ["string"]
    },
    "rollback_triggers": ["string"],
    "monitoring_metrics": ["string"]
  },
  "canary_pass_fail_criteria": [
    {
      "metric": "string",
      "threshold": "string",
      "comparison_baseline": "OLD_PROMPT" | "ABSOLUTE",
      "pass_condition": "string",
      "measurement_method": "string"
    }
  ],
  "confidence_score": number,
  "recommended_human_review": boolean,
  "human_review_focus_areas": ["string"]
}

## CONSTRAINTS

- Compare instruction semantics, not just surface text. Two prompts can be worded differently but produce identical behavior.
- Flag any change to output schema, required fields, enum values, or type constraints as a potential BLOCKER if downstream systems consume structured outputs.
- If the new prompt adds or removes refusal language, assess whether the safety boundary has shifted. A broader refusal boundary may break legitimate workflows; a narrower one may introduce risk.
- For multi-agent systems, assess whether handoff summaries, task descriptions, or role definitions have changed in ways that could break coordination.
- If few-shot examples were added, removed, or reordered, assess the risk of output style drift or bias introduction.
- If tool definitions or function-calling instructions changed, assess whether argument generation accuracy may degrade.
- Consider model-target-specific behavior. A change safe on GPT-4o may break on Claude 3.5 Sonnet or an open-weight model.
- If regression test results are provided, incorporate them as evidence. Do not ignore test failures.
- Set confidence_score between 0.0 and 1.0 reflecting how certain you are in the assessment given the available evidence.
- If confidence_score is below 0.7, set recommended_human_review to true.

To adapt this template, replace each square-bracket placeholder with the actual data from your prompt registry and test infrastructure. The PRODUCTION_CONTEXT should describe where and how the prompt is used, including any compliance requirements. The MODEL_TARGETS field should list every model and provider version where this prompt runs. If you do not have regression test results yet, set REGRESSION_TEST_RESULTS to an empty string and expect a lower confidence score with a strong recommendation to run tests before proceeding. After running the assessment, feed the output into your release gate automation: if migration_verdict is BLOCKED, halt the deployment pipeline. If PROCEED_WITH_CAUTION, require explicit approval from the prompt owner. If SAFE_TO_PROCEED, allow automated promotion with the specified canary configuration.

This prompt is designed to be integrated into a CI/CD release gate for prompt changes. It should be triggered automatically whenever a pull request modifies a prompt template, system instruction, or tool definition. The harness must supply the prompt with a structured diff of the change, the current production prompt, the proposed new prompt, and a manifest of all active workflows, model targets, and user segments that consume the prompt. The output is a machine-readable migration-readiness report that downstream automation can parse to decide whether to block the release, flag it for human review, or allow it to proceed to canary testing.

Input assembly requires three data sources: (1) a diff generated by your prompt version control system, (2) a workflow registry that maps prompt IDs to consuming services, and (3) a model routing table showing which model versions serve which user segments. The harness should serialize these into the [PROMPT_DIFF], [WORKFLOW_MANIFEST], and [MODEL_TARGETS] placeholders respectively. For the [OUTPUT_SCHEMA] placeholder, supply a strict JSON schema that includes blocking_issues (array of objects with severity, affected_workflow, description), canary_pass_criteria (array of measurable conditions), rollout_strategy (string enum: immediate, canary, staged, blocked), and confidence_score (0-1 float). This schema is what your release automation will parse.

Validation and retry logic is critical because a malformed assessment is worse than no assessment. After receiving the model output, the harness must: (1) validate JSON structure against the expected schema, (2) verify that every affected_workflow in blocking_issues maps to a real entry in the supplied [WORKFLOW_MANIFEST] (no hallucinated workflows), (3) check that canary_pass_criteria entries are specific and measurable (reject vague criteria like 'check if it works'), and (4) confirm that confidence_score is present and within range. If validation fails, retry once with the error message appended to the prompt as [PREVIOUS_ERROR]. If the second attempt also fails, escalate to a human release manager with the raw output and validation errors logged. Log every assessment—including the prompt version, model used, timestamp, raw output, and validation result—for auditability.

Model choice matters here. Use a model with strong reasoning and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller or faster models that may miss subtle compatibility issues. Set temperature=0 to maximize determinism. If your organization requires on-premise or air-gapped execution, validate that your chosen open-weight model can reliably produce the required JSON schema before relying on it in the release gate. Human approval is mandatory when the assessment returns rollout_strategy: blocked or when confidence_score < 0.7. For canary and staged strategies, the harness should automatically create a canary deployment ticket with the pass/fail criteria embedded, but still require a release manager to approve the canary before it begins serving traffic.