System Prompt Conflict Diff Analysis Prompt

Use this prompt when you are a release manager, AI platform engineer, or governance team member responsible for shipping a new version of a system prompt to production. The primary job-to-be-done is to prevent instruction conflicts from silently degrading model behavior. A single rewording can invert precedence between a safety policy and a user instruction, disable a guardrail, or introduce a new collision between tool-use authorization and data access boundaries. This prompt is designed to be a gate in your CI/CD pipeline, comparing two versioned system prompts and producing a structured report that focuses exclusively on conflict changes: new collisions, resolved collisions, modified severity, and regression risks. It is not a general text diff; it is a conflict-aware structural comparison for auditable, versioned artifacts.

The ideal input consists of two complete system prompt versions, clearly labeled as [PROMPT_VERSION_A] and [PROMPT_VERSION_B], along with an optional [CONFLICT_CATALOG] that defines known conflict patterns, severity levels, and resolution rules specific to your system. The output is a structured JSON diff report containing a summary of changes, a detailed list of new and resolved conflicts, a severity shift analysis, and a regression risk assessment. This report can be used as a manual review artifact or as a machine-readable signal to block a deployment if high-severity regressions are detected. For high-risk domains such as healthcare, finance, or safety-critical applications, the report should always be reviewed by a human before a prompt is promoted.

Do not use this prompt for simple typo fixes, minor phrasing changes, or when comparing prompts that are structurally identical. A standard text diff is more appropriate for those cases. This prompt is also not a substitute for behavioral evals or red-teaming; it identifies structural conflicts in the instructions themselves, not how the model will actually behave under adversarial pressure. After running this analysis, you should still execute your regression test suites and policy violation probes. The next step is to integrate this prompt into your prompt version control workflow, treating the diff report as a required approval artifact before any system prompt ships.

This template is designed to be pasted directly into your release workflow or CI/CD pipeline. It compares a base system prompt against a candidate version and produces a structured diff report focused exclusively on instruction conflicts, precedence changes, and regression risks. The prompt assumes you have already extracted the full text of both prompt versions and are ready to analyze them side by side.

textCopy
You are a system prompt conflict auditor. Your task is to compare two versions of a system prompt and identify all new, removed, or modified instruction conflicts.

## INPUT

[BASE_PROMPT]

[CANDIDATE_PROMPT]

## INSTRUCTIONS

1. Parse both prompts into individual behavioral directives, policy statements, role boundaries, tool-use rules, refusal conditions, and precedence declarations.
2. Identify every directive pair that could produce contradictory or ambiguous behavior when active simultaneously. Consider:
   - Direct contradictions (e.g., "always refuse X" vs "comply with X when Y")
   - Precedence inversions (e.g., a lower-priority rule now overrides a higher-priority one)
   - Implicit conflicts (e.g., a new policy that indirectly blocks a previously allowed behavior)
   - Scope changes (e.g., a rule that previously applied to all users now applies only to some)
3. Classify each conflict as:
   - NEW: A conflict that did not exist in the base version
   - REMOVED: A conflict that existed in the base version but is resolved in the candidate
   - MODIFIED: A conflict that existed in both versions but changed in severity, scope, or resolution path
   - UNCHANGED: A conflict that persists identically across both versions
4. For each conflict, assign a severity level:
   - CRITICAL: Causes silent policy violations, safety bypasses, or tool misuse in common workflows
   - HIGH: Creates ambiguous behavior that could lead to incorrect outputs under specific conditions
   - MEDIUM: Introduces inconsistency that may confuse users or downstream systems
   - LOW: Minor wording changes that do not materially affect behavior
5. For each NEW or MODIFIED conflict, identify the specific directives involved, explain the contradiction, and describe the regression risk if deployed without resolution.

## OUTPUT FORMAT

Return a JSON object with this exact schema:

{
  "base_version_label": "string (extracted or inferred identifier for the base prompt)",
  "candidate_version_label": "string (extracted or inferred identifier for the candidate prompt)",
  "summary": {
    "total_directives_base": "number",
    "total_directives_candidate": "number",
    "new_conflicts": "number",
    "removed_conflicts": "number",
    "modified_conflicts": "number",
    "unchanged_conflicts": "number",
    "critical_count": "number",
    "high_count": "number",
    "medium_count": "number",
    "low_count": "number"
  },
  "conflicts": [
    {
      "id": "string (unique conflict identifier, e.g., CONFLICT-001)",
      "status": "NEW | REMOVED | MODIFIED | UNCHANGED",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "base_directives": ["string (directive text or summary from base prompt, empty if NEW)"],
      "candidate_directives": ["string (directive text or summary from candidate prompt, empty if REMOVED)"],
      "contradiction": "string (clear explanation of why these directives conflict)",
      "regression_risk": "string (what breaks in production if this conflict is not resolved, empty for REMOVED and UNCHANGED)",
      "resolution_suggestion": "string (recommended fix, precedence rule, or clarification needed)"
    }
  ],
  "deployment_recommendation": "BLOCK | WARN | PROCEED",
  "deployment_reasoning": "string (justification for the deployment recommendation based on conflict severity and count)"
}

## CONSTRAINTS

- Only report conflicts where both directives would be active under the same conditions. Do not flag directives that apply to mutually exclusive scenarios.
- If a directive appears in both versions with identical wording, do not flag it as a conflict unless it now contradicts a new or modified directive.
- If the candidate prompt removes a directive that previously caused a conflict, classify that conflict as REMOVED and note the resolution.
- Do not invent directives that are not present in the provided prompt text.
- If either prompt is empty or unparseable, return a single error object: {"error": "string describing the issue"}.

Before integrating this prompt into a deployment gate, you must replace [BASE_PROMPT] and [CANDIDATE_PROMPT] with the full text of each system prompt version. The output JSON is designed to be machine-readable so your CI/CD pipeline can parse the deployment_recommendation field and automatically block releases when BLOCK is returned. For high-risk production systems, always pair this automated diff with a human review step for any conflict classified as CRITICAL or HIGH. Do not rely solely on the model's severity classification without spot-checking against your organization's specific safety and compliance requirements.

The System Prompt Conflict Diff Analysis Prompt is designed to operate as a deterministic gate within a CI/CD pipeline, not as an ad-hoc review tool. The core integration pattern is a pre-commit or pre-merge hook that triggers the prompt whenever a system prompt file changes in the repository. The harness must supply two complete system prompt versions—[CURRENT_PROMPT] and [NEW_PROMPT]—along with a [CONFLICT_RULESET] that defines known precedence rules, policy categories, and severity thresholds. The model returns a structured diff report that the harness parses, validates, and uses to block or allow the deployment.

Validation is the critical layer. The harness must enforce a strict JSON output schema with required fields: conflict_changes (array of added, removed, or modified conflicts), regression_risks (array of previously resolved conflicts that may re-emerge), and gate_recommendation (one of pass, warn, or block). A post-processing validator should check that every reported conflict includes a source_lines reference that maps back to actual line ranges in the new prompt, that severity classifications match the provided [CONFLICT_RULESET], and that no hallucinated conflicts reference instructions absent from either version. If validation fails, the harness should retry once with a stricter [CONSTRAINTS] block that emphasizes source grounding and line-number accuracy. After two failures, escalate for human review rather than silently passing.

For production deployment gates, integrate the validated gate_recommendation field into your merge request checks. A block recommendation should prevent merging until a human reviewer acknowledges the conflict report. A warn recommendation should create a non-blocking annotation on the pull request with the full diff report attached. Log every run—including model, prompt version, input hashes, validation results, and gate outcome—to an observability store for audit trails. Avoid using this prompt as the sole safety check for high-risk policy changes; pair it with behavioral regression tests that exercise the conflicting instructions against a test suite of adversarial user inputs before any production rollout.