Instruction Version Bump Prompt Template

This prompt is for platform teams that treat system instructions as production artifacts requiring formal version control. Use it when you need to generate a new version of an instruction block that includes a structured changelog, an effective date, and explicit compatibility notes. The core job-to-be-done is producing a release-ready, versioned instruction artifact that can be committed directly to a prompt registry, deployment pipeline, or configuration store. The ideal user is an AI platform engineer, prompt architect, or release manager who already has a previous instruction version and a set of intended changes documented in a changelog or commit history.

This is not a prompt for writing new instructions from scratch. It assumes you already have a previous instruction version and a set of intended changes. The workflow belongs inside your release process, not your ideation phase. Do not use this prompt when you are drafting brand-new system instructions, when you lack a clear changelog of what changed between versions, or when the instruction set is still in early experimentation and not yet treated as a versioned artifact. Using this prompt without a prior version and explicit change list will produce a plausible but ungrounded version bump that lacks traceability to actual decisions.

Before invoking this prompt, ensure you have three inputs ready: the previous instruction block text, a structured or narrative changelog describing what changed and why, and the intended version number or bump type (major, minor, patch). The output is a complete, versioned instruction block with a header containing version metadata, the full instruction body, a formatted changelog section, and compatibility notes. This output should pass automated validation checks for version header presence, changelog completeness, and metadata format before it enters your deployment pipeline. If the instruction set governs a regulated or safety-critical workflow, add a human review step after generation and before rollout.

This template produces a structured, versioned instruction block when you need to formally bump the version of a system prompt, policy document, or agent role definition. It forces the model to output a complete artifact—version header, changelog, effective date, compatibility notes, and the full instruction text—rather than a loose summary. Use this when you treat prompts as production code and need auditable version artifacts that downstream systems, eval pipelines, and governance tools can parse.

textCopy
You are an instruction versioning assistant for production AI systems. Your task is to produce a versioned instruction block from the provided inputs.

## INPUTS
- Current Instruction Text: [CURRENT_INSTRUCTION_TEXT]
- Change Description: [CHANGE_DESCRIPTION]
- Previous Version: [PREVIOUS_VERSION]
- New Version: [NEW_VERSION]
- Effective Date: [EFFECTIVE_DATE]
- Author: [AUTHOR]
- Compatibility Notes: [COMPATIBILITY_NOTES]
- Risk Level: [RISK_LEVEL]

## OUTPUT SCHEMA
Return a JSON object with exactly these fields:
{
  "version": "[NEW_VERSION]",
  "effective_date": "[EFFECTIVE_DATE]",
  "author": "[AUTHOR]",
  "changelog": [
    {
      "type": "added | modified | deprecated | removed | fixed",
      "section": "short section name",
      "description": "what changed and why",
      "previous_behavior": "what the instruction did before",
      "new_behavior": "what the instruction does now"
    }
  ],
  "compatibility": {
    "breaks_existing_sessions": true | false,
    "migration_required": true | false,
    "notes": "[COMPATIBILITY_NOTES]"
  },
  "risk_level": "[RISK_LEVEL]",
  "instruction_text": "the complete updated instruction block"
}

## CONSTRAINTS
- The `instruction_text` field must contain the full updated instruction, not a diff or summary.
- Every change in the changelog must reference a specific section or rule in the instruction text.
- If no changes are detected, return an empty changelog array and set `breaks_existing_sessions` to false.
- Do not invent changes not described in [CHANGE_DESCRIPTION].
- Preserve all unchanged sections verbatim from [CURRENT_INSTRUCTION_TEXT].
- The version string must match [NEW_VERSION] exactly.

Adapt this template by replacing each square-bracket placeholder before sending it to the model. The [CURRENT_INSTRUCTION_TEXT] should contain the full instruction block being versioned—do not truncate it. The [CHANGE_DESCRIPTION] can be a natural-language summary of what changed, but for high-stakes rollouts, prefer a structured list of specific modifications. The [COMPATIBILITY_NOTES] field should explicitly state whether in-flight sessions will break and what migration steps are required. For regulated workflows, set [RISK_LEVEL] to high and route the output through human review before deployment. After generation, validate that the instruction_text field is parseable by your downstream systems and that the version header is present and correct.

This prompt is designed to be called as part of a prompt release pipeline, not as a one-off chat interaction. When a prompt engineer finalizes a new instruction version, the application should programmatically invoke this prompt with the raw instruction text, the previous version number, and the changelog summary. The model's output—a structured version block with metadata—must be validated before it is committed to the prompt registry or deployed to production agents. Treat the output as a machine-consumable artifact that downstream systems (deployment scripts, audit logs, agent configs) will parse.

Wire the prompt into a CI/CD step or an internal admin tool. After receiving the model response, run a schema validator that checks for required fields: version, effective_date, changelog, compatibility_notes, and the full instruction text block. If any field is missing or malformed, retry once with a repair prompt that includes the validation error. Log both the raw output and the validation result. For high-risk production systems, require human approval before the version block is merged—this is a natural gate in a pull-request workflow where a reviewer confirms the changelog accurately reflects the instruction delta.

Choose a model with strong structured-output reliability (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to minimize variation in metadata formatting. Do not use this prompt with small or instruction-following-weak models unless you add a strict JSON schema constraint via function calling or structured output mode. The prompt's value is in producing a consistent, parseable version artifact; if the model cannot reliably emit the metadata fields, the pipeline will break. Store the output alongside the raw instruction in your prompt registry, and use the version field as the source of truth for agent configuration. When rolling back, reference this version block to confirm you are restoring the correct artifact.