Pre-Edit File Snapshot Prompt Template

This prompt is for coding agents preparing to modify a file inside a repository. Before any edit is applied, the agent must capture a structured snapshot of the file's current state: content hash, line count, encoding, and key structural landmarks. This snapshot becomes the ground truth for post-edit verification and rollback comparison. Use this prompt when your agent workflow requires cryptographic proof of pre-edit state, when you need to detect unintended changes after a patch, or when compliance demands an audit trail of every file modification.

The ideal user is an AI engineer or platform developer integrating an LLM into an automated refactoring, migration, or code-generation pipeline. The required context includes filesystem access to the target file, the ability to compute SHA-256 hashes programmatically, and a clear understanding of what constitutes a structural landmark for the file type (e.g., function signatures for Python, exported symbols for TypeScript). The prompt assumes the agent operates in a controlled environment where it can read the file, compute its hash, and store the snapshot before any write operation begins. Do not use this prompt for read-only code analysis, for files the agent is not authorized to modify, or when the file content is too large to hash within your latency budget. For files exceeding 10 MB, consider a streaming hash or a partial structural snapshot rather than a full-content hash.

To implement this safely, wire the snapshot capture as a mandatory pre-edit step in your agent's tool-use loop. Store the snapshot in a structured format (JSON or YAML) alongside a timestamp and the agent's identity. Before applying any patch, validate that the current file hash matches the snapshot hash to confirm no external changes occurred between snapshot and edit. After the edit, compare the post-edit hash against the snapshot to detect any modification. For high-risk workflows, log the snapshot to an append-only audit store and require human review if the pre-edit hash check fails. Avoid using this prompt when the file is expected to change between snapshot and edit (e.g., hot-reloaded configuration files) unless you pair it with a file-locking mechanism.

This prompt template instructs a coding agent to produce a structured, machine-verifiable snapshot of a target file before any modification begins. The snapshot captures the file's content hash, line count, encoding, and key structural landmarks such as function signatures, class definitions, or import blocks. Use this template as a pre-edit gate in automated refactoring pipelines, CI/CD workflows, or any system where edit safety depends on knowing exactly what the file looked like before the agent touched it.

textCopy
You are a coding agent preparing to modify a file. Before making any changes, you must capture a structured snapshot of the file in its current state. This snapshot will be used for post-edit verification and rollback if needed.

## Input
- File path: [FILE_PATH]
- File content: [FILE_CONTENT]
- Snapshot schema: [SNAPSHOT_SCHEMA]
- Structural landmarks to extract: [LANDMARKS]

## Task
Generate a pre-edit snapshot of the file that includes:
1. A cryptographic hash of the full file content using [HASH_ALGORITHM].
2. The total line count.
3. The detected file encoding.
4. A structured extraction of the specified landmarks with their line ranges.
5. A timestamp in ISO 8601 format.

## Output Format
Return a JSON object conforming to the provided snapshot schema. Do not include any text outside the JSON object.

## Constraints
- Do not modify the file.
- If the file content is empty, set line_count to 0 and hash to the hash of an empty string.
- If a requested landmark type is not found, include it with an empty array.
- Report the encoding exactly as detected; do not assume UTF-8.
- If the file content exceeds [MAX_SIZE] characters, hash it in chunks and report the combined hash.

## Example Landmark Types
- function_definitions: function name, signature, and line range
- class_definitions: class name, base classes, and line range
- import_statements: module name and line number
- exports: exported symbol name and line number
- section_headers: header text and line range (for markdown, config files, etc.)

Adapt this template by replacing each square-bracket placeholder with concrete values before sending it to the model. [FILE_PATH] and [FILE_CONTENT] are mandatory inputs supplied by your application layer. [SNAPSHOT_SCHEMA] should be a JSON Schema or TypeScript interface that defines the exact shape you expect back—this is critical for downstream validation. [LANDMARKS] should be a list of landmark types relevant to the file type you are snapshotting: use function_definitions and class_definitions for source code, section_headers for markdown, or top_level_keys for JSON and YAML files. [HASH_ALGORITHM] should be set to sha256 unless your pipeline requires a different algorithm. [MAX_SIZE] should match your application's context window or chunking threshold. After receiving the snapshot, validate the hash against your own computation of the file content before trusting the snapshot for rollback purposes. If the hashes do not match, discard the snapshot and retry or escalate.

The Pre-Edit File Snapshot Prompt is not a standalone utility; it is a gate that must execute before any file modification command is issued by your coding agent. In practice, this means wrapping your agent's edit tool or function with a mandatory pre-hook that calls the LLM with this prompt, passing the target file's raw content and absolute path. The snapshot output—containing the content hash, line count, encoding, and structural landmarks—should be stored as an immutable record in the agent's session state or a dedicated audit log before the edit proceeds. This record becomes the ground truth for post-edit diff verification and, critically, the exact input required for a byte-for-byte rollback if verification fails.

To wire this into an application, implement a capture_snapshot function that reads the file from disk, computes a SHA-256 hash of its contents, and then invokes the LLM with the prompt template. The function must validate the LLM's response against the computed hash before returning: if the hash in the LLM output does not match the hash you computed independently, reject the snapshot and retry (or abort the edit). This validation step prevents a hallucinated hash from corrupting your rollback mechanism. Store the validated snapshot alongside a timestamp, the agent's session ID, and the proposed edit rationale. For high-risk repositories, consider writing the snapshot to an append-only audit log or a dedicated snapshots/ directory tracked separately from the working tree. Model choice matters here: prefer models with strong instruction-following for structured output (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to maximize hash and line-count accuracy. Avoid using this prompt on binary files; gate the harness to only process text files by checking MIME types or file extensions before invocation.

The most common production failure mode is a hash mismatch caused by the model truncating or reformatting the file content in its response. Always validate the hash outside the model's output. A secondary failure mode is the model omitting key structural landmarks (e.g., missing a class definition in a large file), which reduces the snapshot's utility for human review but does not break rollback. To guard against this, implement a lightweight eval that checks for the presence of expected landmark types (functions, classes, imports) based on file extension and flags snapshots with zero detected landmarks for retry. Do not use this prompt as a substitute for version control; it is a runtime safety net for AI-initiated edits, not a replacement for git commit. After implementing the harness, test it with a known file, intentionally corrupt the hash in the LLM response, and confirm that your validation rejects it and prevents the edit from proceeding.