Prompt Change Impact Analysis Prompt

This prompt is a governance tool for release managers and AI platform engineers who must assess the risk of a prompt modification before it reaches production. Its job is to produce a structured blast radius report that identifies affected workflows, downstream systems, and output contracts. Use it when a prompt change is proposed and you need an evidence-backed risk assessment to inform a go/no-go decision. The prompt is not designed for generating code, answering user questions, or evaluating model quality in isolation—it is a release-process control that sits between the pull request and the deployment gate.

The prompt requires several concrete inputs to produce a reliable assessment. You must supply the previous prompt version, the proposed new prompt version, a diff or changelog describing what changed, and a dependency map that lists downstream systems, workflows, or APIs that consume the prompt's output. Optionally, you can provide a [RISK_LEVEL] threshold to calibrate severity scoring and a [REGRESSION_SUITE] reference if you want the analysis to cross-reference known test cases. Without these inputs, the prompt will produce a generic summary that lacks the specificity required for a real release decision. The output is a structured report containing affected components, severity scores per downstream dependency, output contract change flags, and recommended rollback triggers.

Do not use this prompt for trivial changes where the blast radius is already known to be zero—such as fixing a typo in a comment or adjusting whitespace in a system message that does not alter model behavior. It is also not a substitute for running your regression test suite; the impact analysis complements test results but does not replace them. After receiving the report, the next step is to cross-reference the identified risks against your release gate criteria, decide whether to proceed, stage, or block the change, and document the decision with the report as evidence. If the analysis flags high-severity risks to critical downstream systems, require a human review before any promotion decision.

The following prompt is designed to be used by a release manager or prompt engineer before approving a change to a production prompt. It forces the model to analyze the proposed modification, identify every affected workflow and downstream contract, and produce a structured impact report. The template uses square-bracket placeholders so you can inject the current prompt, the proposed change, known dependencies, and your risk tolerance without rewriting the core instructions.

textCopy
You are a release safety analyst for an AI product. Your task is to assess the blast radius of a proposed prompt change before it is deployed.

## INPUTS
- CURRENT PROMPT:
[CURRENT_PROMPT]

- PROPOSED CHANGE (diff or full new prompt):
[PROPOSED_CHANGE]

- KNOWN DEPENDENCIES (workflows, tools, downstream systems, output contracts):
[DEPENDENCIES]

- RISK TOLERANCE LEVEL: [RISK_LEVEL]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "change_summary": "One-sentence summary of the modification.",
  "affected_workflows": [
    {
      "workflow_name": "string",
      "impact_type": "direct | indirect | none",
      "expected_behavior_change": "string",
      "severity": "low | medium | high | critical",
      "evidence": "Quote or reference from the prompt diff that supports this assessment."
    }
  ],
  "downstream_systems_affected": [
    {
      "system_name": "string",
      "contract_risk": "none | format_change | semantic_drift | breaking",
      "mitigation": "string"
    }
  ],
  "output_contract_changes": [
    {
      "field_or_behavior": "string",
      "before": "string",
      "after": "string",
      "breaking": true | false
    }
  ],
  "overall_severity_score": "low | medium | high | critical",
  "rollback_triggers": [
    "Observable condition that should trigger an automatic or manual rollback."
  ],
  "recommended_precautions": [
    "Actionable step to reduce risk before deployment."
  ],
  "confidence": "high | medium | low",
  "unknowns": [
    "Area where more information is needed to fully assess risk."
  ]
}

## CONSTRAINTS
- Only report impacts you can trace to specific differences between CURRENT_PROMPT and PROPOSED_CHANGE.
- If a dependency is not listed in KNOWN DEPENDENCIES, note it as an unknown rather than assuming it is unaffected.
- For severity scoring, consider: number of affected workflows, presence of breaking output contract changes, and downstream system coupling.
- If RISK_LEVEL is "low", you may skip low-severity items. If "high", include every detectable impact.
- Do not fabricate dependencies or impacts. If evidence is thin, lower your confidence.

To adapt this template, replace the placeholders with concrete values from your change management process. [CURRENT_PROMPT] should be the exact system or task prompt currently in production. [PROPOSED_CHANGE] can be a full replacement prompt or a unified diff. [DEPENDENCIES] should list every known consumer of the prompt's output: downstream APIs, UI surfaces, agent tools that parse the response, logging pipelines, and eval suites. Set [RISK_LEVEL] to match your release policy. After running the prompt, validate the output JSON against the schema before using it in a release gate. For high-risk changes, have a human review the affected_workflows and rollback_triggers before approving deployment.

This prompt is designed to operate as a pre-approval risk assessment gate in a prompt release pipeline, not as a standalone chatbot interaction. The harness should invoke the model with a structured payload containing the diff of the proposed prompt change, the current prompt version, affected workflow definitions, and a list of downstream consumers. The output is a machine-readable blast radius report that feeds into a release decision system. Because the analysis directly influences whether a prompt ships to production, the harness must enforce strict input validation, output schema conformance, and a mandatory human review step before any automated promotion or rollback action is taken.

Input assembly requires collecting the old and new prompt text (typically via a git diff or version control API), a manifest of registered workflows that reference the prompt, and a list of downstream systems or APIs that consume the prompt's output. Package these into the [PROMPT_DIFF], [AFFECTED_WORKFLOWS], and [DOWNSTREAM_CONSUMERS] placeholders. The harness should validate that the diff is non-empty, that workflow entries include unique identifiers and expected output schemas, and that downstream consumers are tagged with criticality levels. Model selection matters: use a model with strong reasoning and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to maximize deterministic severity scoring. Enable JSON mode or structured outputs to enforce the report schema. Retry logic should be minimal—if the model fails to produce valid JSON after one retry with a repair prompt, escalate to a human operator rather than silently falling back.

Output handling must parse the JSON report and validate every field: severity scores must be integers in the defined range, affected workflow IDs must match the input manifest, and rollback trigger recommendations must be one of the enumerated values. Log the full report, input diff, and model trace to an audit store for post-incident review. The human review gate is non-negotiable for any change scoring HIGH or CRITICAL severity, or any change where the model recommends an automatic rollback trigger. Present the report in a review UI that highlights affected workflows, severity justifications, and recommended actions. Only after explicit approval should the harness proceed to canary deployment or full promotion. Avoid wiring this prompt directly to automated rollback without human confirmation—false positives in impact analysis can block legitimate fixes, and false negatives can ship breaking changes.