Prompt Version Diff Summary for Release Notes Prompt Template

This prompt is designed for prompt engineers and release managers who need to translate a technical, line-by-line diff between two prompt versions into a clear, categorized changelog suitable for release notes. The primary job-to-be-done is communication: taking a raw change artifact that is meaningful to engineers and converting it into a structured summary that downstream teams, API consumers, and internal stakeholders can act on. Use this when you have a completed diff between a baseline and a release candidate and you need to document the impact of those changes before or during a deployment.

The ideal user has access to the exact prompt text for both versions and understands the workflows those prompts power. Required context includes the raw diff, the affected workflow names, and any known downstream consumers. This prompt is not a replacement for a full impact analysis, a regression test suite, or a canary evaluation. It is the documentation artifact that summarizes the change. Do not use this prompt to decide whether a change is safe to ship; use it to explain what changed after you have already run your eval gates and made a promotion decision. If you need a go/no-go recommendation, use the Automated Promotion Gate Decision Prompt Template instead.

Before running this prompt, ensure you have a clean, complete diff. Partial diffs or diffs that include unrelated formatting changes will produce noisy changelogs. The prompt works best when the diff is focused on semantic changes to instructions, output schemas, tool definitions, or behavioral constraints. After generating the changelog, review it for accuracy against the original diff, and consider pairing it with the Prompt Change Impact Analysis Prompt Template to assess blast radius before publishing the release notes to downstream consumers.

This template takes a raw diff between two prompt versions and produces a human-readable changelog suitable for release notes, stakeholder communication, or automated changelog generation in CI/CD pipelines. It categorizes changes by impact level, identifies affected workflows, and flags breaking changes that downstream consumers must address. Use this when you need consistent, structured documentation of what changed between prompt versions without manually writing release notes.

textCopy
You are a prompt release engineer documenting changes between two versions of a production prompt. Your task is to produce a structured, human-readable changelog from a raw prompt diff.

## INPUT
[PROMPT_DIFF]

## CONTEXT
- Previous version: [PREVIOUS_VERSION_ID]
- New version: [NEW_VERSION_ID]
- Affected workflows: [AFFECTED_WORKFLOWS]
- Deployment environment: [DEPLOYMENT_ENVIRONMENT]

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "release_summary": {
    "previous_version": string,
    "new_version": string,
    "change_type": "major" | "minor" | "patch",
    "summary": string,
    "breaking_changes_count": number,
    "total_changes_count": number
  },
  "changes": [
    {
      "category": "instruction_change" | "schema_change" | "tool_change" | "example_change" | "constraint_change" | "format_change" | "dependency_change",
      "impact": "breaking" | "high" | "medium" | "low",
      "location": string,
      "before": string,
      "after": string,
      "rationale": string,
      "affected_workflows": [string],
      "migration_notes": string | null
    }
  ],
  "breaking_changes": [
    {
      "change_index": number,
      "severity": "critical" | "high",
      "description": string,
      "required_action": string,
      "deadline": string | null
    }
  ],
  "workflow_impact_summary": [
    {
      "workflow": string,
      "impact_level": "none" | "low" | "medium" | "high" | "breaking",
      "affected_components": [string],
      "recommended_testing": string
    }
  ],
  "compatibility_notes": string,
  "rollback_considerations": string
}

## CONSTRAINTS
- Classify every change into exactly one category from the allowed list.
- If a change alters output format, required fields, or tool signatures, mark it as breaking.
- For each breaking change, provide a specific required action for downstream consumers.
- If no breaking changes exist, the breaking_changes array must be empty, not omitted.
- Migration notes must be null if no migration is required, not an empty string.
- The summary must be a single paragraph under 200 words.
- Do not invent changes not present in the diff.
- If the diff is empty or unparseable, return a single change entry with category "unknown" and impact "low" explaining the situation.

## EXAMPLES
[EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your actual data. The [PROMPT_DIFF] should contain the raw unified diff or side-by-side comparison between the two prompt versions. The [EXAMPLES] placeholder should include one or two example changelogs showing the expected tone and detail level for your organization. Set [RISK_LEVEL] to "high" if the prompt handles regulated, safety-critical, or revenue-sensitive workflows—this signals the model to be more conservative in its impact assessments and to flag borderline changes as higher severity. After generation, validate the JSON schema before publishing the changelog. For high-risk deployments, have a human reviewer confirm the breaking change classifications and required actions before distribution.

This prompt is designed to be called programmatically as a step in your prompt release pipeline, typically after a git diff or prompt registry comparison has been generated. The harness should construct the [PROMPT_DIFF] input by extracting the raw diff between the current production prompt version and the release candidate. If your prompt store uses structured records, preprocess the diff to include field-level changes (e.g., system_prompt, temperature, tools) rather than raw text diffs alone. The [AFFECTED_WORKFLOWS] input should be populated from your service catalog or a metadata file that maps prompt IDs to downstream consumers, ensuring the summary accurately reflects blast radius.

Wire the prompt into your CI/CD system (e.g., GitHub Actions, GitLab CI, Jenkins) as a post-diff job. Construct the API call to your model provider with explicit response_format set to JSON schema matching the expected output structure. Implement a retry wrapper with exponential backoff (3 attempts, starting at 1-second delay) to handle transient API failures. On each attempt, log the request ID, latency, and token usage. After receiving a response, run a strict JSON schema validator against the output before accepting it. If validation fails, retry with the validation error appended to the [CONSTRAINTS] field to guide the model toward a conformant output. After 3 failed validation attempts, fail the pipeline step and alert the release manager.

For logging and auditability, emit structured log events at each stage: prompt_diff_generated, api_call_started, api_call_completed, validation_passed, and release_notes_published. Include the prompt version hash, diff size in tokens, and validation status in each event. Store the generated release notes as a pipeline artifact and attach them to the release record. If your release process includes a manual approval gate, surface the notes there. Avoid using this prompt for diffs exceeding your model's context window; for large changes, chunk the diff by workflow or section and aggregate summaries. Never ship release notes without human review when the diff includes changes to safety policies, refusal behavior, or regulated workflows.