Safe Patch Application with Revert Option Prompt

This prompt is designed for coding agents that must apply a patch file to a target file and produce a guaranteed rollback path. The core job-to-be-done is atomic, verifiable file modification: the agent receives the original file content and a patch, then generates the patched file content, a reverse patch, and a verification that the reverse patch restores the original file exactly. The ideal user is an engineering lead or platform engineer integrating AI into automated refactoring pipelines, CI/CD jobs, or AI-assisted code review tools where a failed edit must be undone atomically without manual intervention. This prompt assumes you already have the original file content, the patch content, and a mechanism to apply and verify patches outside the model. It does not generate the patch itself; it orchestrates safe application and round-trip verification.

Use this prompt when your agent modifies files in environments where edit safety is non-negotiable. Concrete scenarios include: automated dependency upgrades that must roll back on test failure, AI-suggested refactoring applied across a monorepo with per-file revert capability, or code review bots that apply suggested fixes but must preserve the ability to undo each change independently. The prompt requires three inputs: the complete original file content, the patch to be applied, and a target file path for logging. The output contract is strict: a patched file, a reverse patch, and a verification step that proves the reverse patch restores the original content byte-for-byte. This round-trip verification is the safety guarantee—without it, you have no proof that rollback will work.

Do not use this prompt when the patch itself is untrusted, when the original file content is unavailable, or when the patching mechanism is outside your control. This prompt is not a patch generator; it applies existing patches safely. It is also not a substitute for git version control or filesystem snapshots—it is a programmatic safety net for automated agents operating in environments where those mechanisms may not be available or practical. Before deploying, ensure your harness validates the reverse patch against the original content and logs the hash chain for auditability. If the verification step fails, the agent must not proceed with the patched file; escalate for human review or fall back to a known-good state.

This prompt template is designed to be wired into a coding agent's tool-use or edit-verification workflow. It instructs the agent to apply a patch, generate a corresponding reverse patch, and verify that applying the reverse patch restores the original file content exactly. The template uses square-bracket placeholders for all dynamic inputs, making it straightforward to integrate into an application harness that supplies the target file, the patch content, and any operational constraints.

textCopy
You are a precise file-editing agent operating in a high-integrity mode. Your task is to apply a patch to a file, generate a reverse patch, and verify the round-trip fidelity of the operation.

## INPUTS
- **Target File Path:** [TARGET_FILE_PATH]
- **Original File Content:**

[ORIGINAL_FILE_CONTENT]

codeCopy
- **Patch to Apply:**
```diff
[PATCH_CONTENT]

CONSTRAINTS

• [CONSTRAINTS]

PROCEDURE

1. Validate Pre-conditions: Check that the original file content matches the expected base for the patch. If the patch does not apply cleanly, stop and report the conflict.
2. Apply Patch: Apply the provided patch to the original file content to produce the patched file content.
3. Generate Reverse Patch: Create a reverse patch that, when applied to the patched file content, restores the original file content exactly.
4. Verify Round-Trip: Apply the reverse patch to the patched file content and confirm the result is byte-for-byte identical to the original file content.
5. Report Results: Output the results in the schema defined below.

OUTPUT SCHEMA

You must respond with a single JSON object conforming to this structure:

jsonCopy
{
  "patch_applied_successfully": boolean,
  "patched_file_content": "string (full content after patch application, or null if failed)",
  "reverse_patch": "string (the generated reverse patch in unified diff format, or null if failed)",
  "round_trip_verified": boolean,
  "round_trip_diff": "string (diff between original and round-tripped content; empty string if identical)",
  "errors": ["string (descriptions of any failures encountered)"]
}

RISK LEVEL

[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with the appropriate values from your application context. For [CONSTRAINTS], include any operational rules such as file size limits, disallowed operations, or required approval steps. The [RISK_LEVEL] placeholder should be set to high when modifying production configurations, security-sensitive files, or critical infrastructure code—this should trigger additional logging and human review in your harness. For lower-risk edits, set it to low or medium to allow automated processing. Always validate the output JSON against the schema before accepting the result, and log the full response for audit purposes.

This prompt is designed to be called as a transactional step inside a coding agent or CI pipeline, not as a standalone chat interaction. The harness must treat the model's output as a structured payload containing three artifacts: the patched file content, the reverse patch, and a round-trip verification report. Before any file is written to disk, the harness validates that all three artifacts are present, that the reverse patch is syntactically valid for the target diff format, and that the verification report explicitly confirms the reverse patch restores the original content byte-for-byte. If any artifact is missing or the verification fails, the harness must abort the patch application and retain the original file untouched.

The recommended implementation flow is: (1) snapshot the target file with a content hash and backup copy; (2) assemble the prompt with the original file content, the forward patch, and the required output schema; (3) call the model with response_format set to a strict JSON schema that enforces the three output fields; (4) validate the JSON response, checking that verification.round_trip_success is true and that reverse_patch is non-empty; (5) apply the forward patch to a temporary copy of the original file; (6) apply the reverse patch to that temporary copy; (7) hash the result and compare it to the original snapshot hash; (8) only if the hashes match, write the patched file to the target location and log the audit record. This double-verification—model-reported plus harness-executed—catches cases where the model hallucinates a verification claim without actually producing a correct reverse patch.

For model choice, prefer models with strong code-diff reasoning and structured output support, such as Claude 3.5 Sonnet or GPT-4o with JSON mode enabled. Set temperature to 0 to maximize deterministic patch generation. Implement a retry budget of 2 attempts: if the first response fails schema validation or round-trip verification, retry with the same prompt plus the validation error message appended to [CONSTRAINTS]. If the second attempt also fails, escalate to a human reviewer with the original file, the forward patch, and both failed model responses. Log every attempt with timestamps, model version, input hashes, and verification results for auditability. Never apply a patch directly from model output without the harness-level round-trip hash check, even if the model's verification field claims success.