System Prompt Hotfix Template

This prompt is for on-call engineers who must deploy an emergency fix to a production system prompt. Use it when a behavioral policy is causing active harm in production: safety bypasses, critical refusal failures, data leakage, or severe user-facing degradation that cannot wait for a standard release cycle. The prompt produces a structured hotfix procedure with severity justification, minimal change scope, expedited testing steps, deployment instructions, and post-hotfix cleanup requirements. It assumes you already have an incident open, the current system prompt version identified, and the problematic behavior documented.

Before using this prompt, confirm that the incident meets emergency criteria. The behavior must be actively causing harm right now—not a theoretical edge case discovered during a review. You need the incident ID, a link to the current system prompt version in your policy repository, a concrete example of the failing behavior (user input, assistant output, and expected output), and the specific policy clause or instruction that is failing. Without these inputs, the hotfix procedure will lack the precision needed for a safe emergency change. The prompt is designed to enforce minimal change scope: it will reject broad rewrites and push you toward the smallest surgical edit that stops the active harm.

Do not use this prompt for routine policy updates, A/B test variants, or changes that can follow the standard versioning and release gate process. Do not use it when you lack an open incident or when the behavior is merely suboptimal rather than actively harmful. If the fix requires coordinated changes across multiple system prompts, tool authorization policies, or model routing rules, this prompt is insufficient—you need the broader incident commander workflow. After the hotfix is deployed, you must follow the post-hotfix cleanup steps this prompt generates, which include creating a permanent fix ticket, updating regression tests, and documenting why the emergency path was necessary.

This template produces a structured hotfix procedure for on-call engineers who need to deploy an emergency policy fix to a production system prompt. It forces explicit severity justification, minimal change scope, expedited testing, and post-hotfix cleanup requirements before the incident is considered resolved. Use this when a behavioral regression, safety bypass, or policy violation is actively affecting users and cannot wait for a standard release cycle.

textCopy
You are an AI operations engineer executing an emergency system prompt hotfix.

INCIDENT CONTEXT:
- Incident ID: [INCIDENT_ID]
- Incident Link: [INCIDENT_LINK]
- Current System Prompt Version: [CURRENT_VERSION]
- Affected Behavior: [AFFECTED_BEHAVIOR]
- User-Visible Impact: [USER_IMPACT]
- Detection Time: [DETECTION_TIME]

SEVERITY JUSTIFICATION:
- Severity Level: [SEVERITY_LEVEL]
- Justification: [SEVERITY_JUSTIFICATION]
- Users Affected: [USERS_AFFECTED]
- Revenue or SLA Impact: [BUSINESS_IMPACT]

HOTFIX SCOPE:
- Change Description: [CHANGE_DESCRIPTION]
- Minimal Change Diff: [MINIMAL_DIFF]
- Capabilities Removed: [CAPABILITIES_REMOVED]
- Capabilities Added: [CAPABILITIES_ADDED]
- Constraints Modified: [CONSTRAINTS_MODIFIED]

EXPEDITED TESTING:
- Test Cases (minimum 5): [TEST_CASES]
- Regression Checks: [REGRESSION_CHECKS]
- Adversarial Probe Results: [ADVERSARIAL_RESULTS]
- Pass/Fail Threshold: [PASS_THRESHOLD]

DEPLOYMENT STEPS:
1. [DEPLOYMENT_STEP_1]
2. [DEPLOYMENT_STEP_2]
3. [DEPLOYMENT_STEP_3]
4. Canary Percentage: [CANARY_PERCENTAGE]
5. Monitoring Duration: [MONITORING_DURATION]
6. Rollback Trigger: [ROLLBACK_TRIGGER]

POST-HOTFIX CLEANUP:
- Permanent Fix Required: [PERMANENT_FIX_REQUIRED]
- Root Cause Ticket: [ROOT_CAUSE_TICKET]
- Policy Version to Create: [NEW_VERSION]
- Changelog Entry: [CHANGELOG_ENTRY]
- Stakeholder Communication: [STAKEHOLDER_COMMUNICATION]
- Cleanup Deadline: [CLEANUP_DEADLINE]

OUTPUT_SCHEMA:
{
  "hotfix_id": "string",
  "incident_id": "string",
  "severity": {
    "level": "string",
    "justification": "string",
    "users_affected": "integer",
    "business_impact": "string"
  },
  "change": {
    "description": "string",
    "minimal_diff": "string",
    "capabilities_removed": ["string"],
    "capabilities_added": ["string"],
    "constraints_modified": ["string"]
  },
  "testing": {
    "test_cases": [{"input": "string", "expected": "string", "actual": "string", "pass": "boolean"}],
    "regression_checks": [{"check": "string", "pass": "boolean"}],
    "adversarial_probes": [{"probe": "string", "result": "string", "safe": "boolean"}],
    "overall_pass": "boolean"
  },
  "deployment": {
    "steps": ["string"],
    "canary_percentage": "integer",
    "monitoring_duration_minutes": "integer",
    "rollback_trigger": "string",
    "status": "string"
  },
  "cleanup": {
    "permanent_fix_required": "boolean",
    "root_cause_ticket": "string",
    "new_version": "string",
    "changelog_entry": "string",
    "stakeholder_communication": "string",
    "deadline": "string"
  }
}

CONSTRAINTS:
- The minimal_diff must be the smallest possible change that resolves the incident.
- Do not introduce unrelated policy changes, refactors, or improvements.
- Every test case must include input, expected output, actual output, and pass/fail.
- If any adversarial probe fails, the hotfix must not proceed to full deployment.
- The rollback trigger must be a specific, measurable condition, not a judgment call.
- Post-hotfix cleanup must include a permanent fix ticket and a deadline within 5 business days.
- If severity is critical, require human approval before canary promotion beyond 10%.

Adapt this template by replacing each square-bracket placeholder with incident-specific values. The [MINIMAL_DIFF] field is the most important: it must contain only the exact change required to stop the active incident, with no unrelated improvements. If you cannot articulate the minimal diff in one sentence, the change is too large for a hotfix and should follow the standard release process instead. Wire the OUTPUT_SCHEMA into your deployment pipeline so the structured JSON can gate canary promotion automatically. After the hotfix is deployed, the cleanup section becomes your post-incident action tracker—do not close the incident until the permanent fix is merged and the new policy version is created.

The System Prompt Hotfix Template is designed for high-severity incidents where a production system prompt is causing active harm—safety violations, broken tool calls, or policy bypasses. This prompt is not a casual editor. It must be wired into a controlled incident response pipeline that enforces justification, minimal change scope, expedited testing, and mandatory post-hotfix cleanup. The implementation harness should treat this prompt as the first step in a gated deployment process, not a standalone fix.

Wire the prompt into an incident management tool (PagerDuty, Opsgenie, or a custom Slack command) that triggers when an on-call engineer acknowledges a policy-related incident. The harness must inject the required inputs: [INCIDENT_ID], [SEVERITY_LEVEL], [AFFECTED_POLICY_VERSION], [OBSERVED_FAILURE_MODE], [USER_IMPACT_DESCRIPTION], and [PROPOSED_FIX_SCOPE]. After the model returns the structured hotfix procedure, validate the output against a strict schema: severity justification must be non-empty, change scope must be bounded to a single policy section, and the rollback plan must reference a specific previous version. If validation fails, retry once with a more constrained prompt; if it fails again, escalate to the incident commander for manual authoring. Log every hotfix generation attempt with the incident ID, model version, input parameters, and validation results for auditability.

Before deployment, route the generated hotfix through a mandatory approval step. For severity-1 incidents, require explicit human approval from the incident commander. For severity-2, allow automated deployment only if the change scope is limited to a single guardrail or refusal rule and the canary test passes against a golden dataset of known failure cases. The harness must also schedule a post-hotfix cleanup task—within 24 hours for severity-1, within the next business week for severity-2—that triggers the System Prompt Versioning Template to create a proper versioned record of the permanent fix. Never allow a hotfix to become the permanent system prompt without going through the full versioning and release gate process. The hotfix template is a bridge, not a destination.