Edit Safety Checklist Prompt for File Modification

This prompt is for AI coding agents that modify files inside real repositories. Before any edit touches disk, the agent must self-assess readiness across file permissions, git status, backup existence, dependency impacts, and test coverage. The output is a structured go/no-go checklist that acts as a pre-flight gate in automated refactoring pipelines. Use this when you need a deterministic safety decision before file mutation, not after. This prompt belongs in the agent's tool-use loop immediately before any file-write operation. It does not replace post-edit verification, rollback discipline, or human approval for high-risk changes.

The ideal user is an engineering lead or platform engineer integrating AI coding agents into CI/CD, refactoring, or codebase automation workflows. Required context includes the target file path, the proposed edit description, the current git status of the repository, and any organizational edit policies (e.g., 'never edit generated files,' 'require approval for production configs'). The agent should have access to file metadata (permissions, size, encoding), git diff output, and dependency graph information before invoking this prompt. Without this context, the checklist will produce false confidence or unnecessary blocks.

Do not use this prompt for read-only operations, code exploration, or patch generation. It is specifically for the moment before a file-write call. Do not use it as a substitute for post-edit verification prompts, rollback decision prompts, or human review workflows. If the edit is trivial (e.g., a single-line comment change in a non-critical file), the checklist overhead may be excessive. If the edit is high-risk (e.g., production configuration, database schema, security-sensitive code), this prompt should gate the edit but must be followed by additional verification and approval steps. The checklist is a necessary but not sufficient safety measure.

This prompt template is designed to be pasted into your coding agent's pre-edit tool or system instructions. It forces the agent to perform a structured safety assessment before any file modification, acting as a pre-flight gate. The agent must evaluate file permissions, git status, backup existence, dependency impacts, and test coverage before receiving authorization to proceed. The output is a machine-readable JSON checklist that your application harness can parse to automatically approve low-risk edits or escalate high-risk ones for human review.

textCopy
You are a coding agent operating in a repository. Before you modify any file, you must complete this Edit Safety Checklist. Do not proceed with any file modification until you have produced and evaluated this checklist.

**Target File:** [TARGET_FILE_PATH]
**Proposed Change Summary:** [CHANGE_DESCRIPTION]
**Edit Scope:** [EDIT_SCOPE]

**Instructions:**
1. Inspect the target file's current state, permissions, and git status.
2. Analyze the proposed change for dependency impacts and test coverage.
3. Produce a JSON object conforming to the schema below. The `go_no_go` field must be `"go"` only if ALL critical checks pass.

**Output Schema:**
{
  "target_file": "string",
  "checks": {
    "file_permissions": {
      "status": "pass" | "fail" | "warn",
      "detail": "string explaining current permissions and any risk"
    },
    "git_status": {
      "status": "pass" | "fail" | "warn",
      "detail": "string with branch, dirty state, and last commit info"
    },
    "backup_exists": {
      "status": "pass" | "fail",
      "detail": "string confirming backup location or absence"
    },
    "dependency_impact": {
      "status": "pass" | "fail" | "warn",
      "detail": "string listing affected callers, imports, or configs"
    },
    "test_coverage": {
      "status": "pass" | "fail" | "warn",
      "detail": "string identifying relevant tests or coverage gaps"
    },
    "edit_boundary": {
      "status": "pass" | "fail",
      "detail": "string confirming the edit stays within declared scope"
    }
  },
  "go_no_go": "go" | "no_go",
  "risk_level": "low" | "medium" | "high",
  "blocking_reasons": ["string array of reasons if no_go"],
  "recommended_actions": ["string array of actions to take before retrying"]
}

**Constraints:**
- If the file is outside the declared [EDIT_SCOPE], `edit_boundary` must fail.
- If the working directory is dirty with unrelated changes, `git_status` must warn.
- If no backup mechanism is available, `backup_exists` must fail and `go_no_go` must be `"no_go"`.
- If `risk_level` is `"high"`, recommend human review regardless of other checks.

To adapt this template, replace the square-bracket placeholders at runtime. [TARGET_FILE_PATH] should be the absolute or repository-relative path to the file being edited. [CHANGE_DESCRIPTION] should be a one-sentence summary of the intended modification. [EDIT_SCOPE] defines the allowed boundary—this could be a single function, a module, or a directory. If your agent operates in a sandboxed environment without git, remove the git_status check or replace it with an equivalent state-verification step. For high-risk repositories, add additional checks such as required_approvers or protected_branch to the schema before deployment.

After pasting this prompt, wire the JSON output into your application's edit gate. Parse the go_no_go field programmatically: if "no_go", block the edit and log the blocking_reasons for the operator. If "go" but risk_level is "high", route to a human approval queue with the full checklist payload. Do not rely on the agent to self-enforce—the application harness must be the final arbiter. For eval purposes, test this prompt against known-safe and known-dangerous edit scenarios and measure whether the go_no_go decision matches your expected outcome in at least 95% of cases before shipping.

The Edit Safety Checklist prompt is designed to run as a synchronous pre-flight gate before any file modification is committed. In an agent architecture, this means the prompt executes after the agent has selected a target file and proposed an edit plan but before it opens the file for writing. The harness should treat the checklist output as a structured decision: a go result allows the edit to proceed, a no-go result blocks the edit and routes to human review or escalation, and a conditional result requires the agent to resolve specific checklist items before retrying. This gate pattern prevents the most common production failures—editing generated files, modifying production configuration without approval, or touching files outside the agent's declared scope.

To implement this harness, wrap the prompt call in a function that accepts the file path, proposed edit summary, and repository context as inputs. The function should call the LLM with the prompt template, parse the JSON response into a typed object with fields decision (enum: go, no-go, conditional), checklist_items (array of objects with item, status, evidence), and rationale (string). Validate the response schema immediately: if the model returns malformed JSON or missing required fields, retry once with a repair prompt that includes the parse error. If the second attempt also fails, default to no-go and escalate. Log every checklist invocation with the file path, decision, and full checklist output to an audit store—this is essential for debugging false positives and tuning checklist thresholds over time.

For model choice, use a fast, instruction-following model (such as Claude 3.5 Haiku or GPT-4o-mini) rather than a large reasoning model. The checklist task is classification and structured output generation, not deep analysis; latency matters because this gate runs on every edit attempt. Set temperature=0 to maximize output consistency across repeated runs on the same inputs. If your pipeline uses tool-calling APIs, you can define the checklist output schema as a tool response format, which improves schema adherence. For high-risk repositories (production infrastructure, security-critical code), add a second validation step after the LLM call: run a deterministic check that verifies the file is not on a deny list of paths (e.g., .gitignore-excluded patterns, generated directories, deployment secrets) regardless of what the model returns. The model's checklist is a probabilistic guard; the deterministic deny list is a hard guard. Both belong in the harness.

When integrating this into an agent loop, avoid calling the checklist on every trivial file touch. Gate invocation on edit intent: the agent should request a checklist only when it plans to modify file contents, not when it reads or stats a file. Cache checklist results per file per task session to avoid redundant calls when the agent revisits the same file. If the agent's edit plan changes materially after the initial checklist, invalidate the cache and re-run. Finally, build an eval suite that tests the harness end-to-end: feed it known-safe and known-unsafe edit scenarios, verify that go decisions never appear for unsafe edits, and measure the false-positive rate on safe edits. Tune the prompt's [RISK_LEVEL] threshold and checklist item wording based on eval results, not intuition.