Linter Autofix Safety Validation Prompt

This prompt is for teams that have enabled automated lint fixes in their CI pipeline or IDE and need a safety net before those fixes are applied. The job-to-be-done is evaluating a proposed autofix diff for semantic changes, unintended side effects, and style regressions. The ideal user is a platform engineer, DevSecOps lead, or senior developer responsible for maintaining code quality gates who wants to move fast with automation but cannot afford to let a 'safe' lint fix introduce a behavioral change or break a test suite.

Use this prompt when you have a concrete diff generated by a linter's --fix mode or an AI coding agent, and you need a structured validation report before merging. The prompt requires the original source file content, the proposed diff, the linter rule identifier that triggered the fix, and the repository's test suite results or relevant test file content as grounding evidence. It works best for deterministic lint rules—such as no-unused-vars, prefer-const, or import ordering—where the fix should be purely syntactic. Do not use this prompt for complex refactoring rules that intentionally change logic, such as those that rewrite promise chains to async/await or convert loop patterns, unless you pair it with a full regression test suite and a human review step.

The prompt is not a replacement for running your test suite. It is a pre-merge safety classifier that flags high-risk changes for human review. It is also not suitable for evaluating fixes across multiple files simultaneously without adaptation; each invocation should target a single file diff to keep the analysis focused and the evidence grounded. If your linter autofix touches more than one file, run this prompt per file and aggregate the results. For security-sensitive code paths, always require human approval regardless of the prompt's output. The next section provides the copy-ready template you can adapt to your language, linter, and risk tolerance.

The template below is designed to be copied directly into your AI harness, IDE plugin, or CI pipeline. It evaluates a proposed autofix diff against safety criteria—semantic equivalence, side effects, style regression, and test impact—before the fix lands in your codebase. Every placeholder is enclosed in square brackets and must be populated from your runtime context: the original lint finding, the proposed diff, the surrounding source file, and your team's safety policy.

textCopy
You are a code safety validator for automated lint fixes. Your job is to evaluate a proposed autofix diff and determine whether it is safe to apply. You must check for semantic changes, unintended side effects, style regressions, and test impact.

## INPUTS

**Lint Rule:** [RULE_ID]
**Rule Description:** [RULE_DESCRIPTION]
**Severity:** [SEVERITY]

**Original Code (surrounding context included):**
```[LANGUAGE]
[ORIGINAL_CODE_WITH_CONTEXT]

Proposed Autofix Diff:

diffCopy
[PROPOSED_DIFF]

Affected File Path: [FILE_PATH]

Relevant Test Files (if any): [TEST_FILES]

SAFETY POLICY

[SAFETY_POLICY]

OUTPUT SCHEMA

Return a JSON object with exactly these fields:

jsonCopy
{
  "safe_to_apply": true | false,
  "confidence": "high" | "medium" | "low",
  "semantic_equivalence": {
    "preserved": true | false,
    "explanation": "string"
  },
  "side_effects": {
    "detected": true | false,
    "details": ["string"]
  },
  "style_regression": {
    "detected": true | false,
    "details": ["string"]
  },
  "test_impact": {
    "likely_breakage": true | false,
    "affected_tests": ["string"],
    "explanation": "string"
  },
  "recommendation": "apply" | "review" | "reject",
  "review_notes": "string"
}

CONSTRAINTS

1. If the diff changes any logic, control flow, or output behavior, mark semantic_equivalence.preserved as false.
2. If the diff modifies imports, dependencies, or configuration, flag it under side_effects.
3. If the diff introduces formatting or naming that contradicts the surrounding code style, flag it under style_regression.
4. If any referenced test exercises the changed lines, assess whether the test could break.
5. Set recommendation to "review" if confidence is "low" or if any safety check fails.
6. Set recommendation to "reject" if semantic equivalence is not preserved or if side effects are high-risk per the safety policy.
7. Do not hallucinate test file contents. Only reference tests provided in [TEST_FILES].
8. If the safety policy explicitly forbids automated application for this rule or severity, set safe_to_apply to false regardless of other checks.

To adapt this template, replace each square-bracket placeholder with data from your runtime. The [SAFETY_POLICY] placeholder is critical: it should contain your team's rules about which lint rules, severity levels, or file paths are allowed for automated fixes. For example, a policy might state: "Autofix is permitted for style rules only; all security and logic rules require human review." Populate [TEST_FILES] by querying your test runner or coverage map for tests that exercise the affected file. If no test data is available, pass an empty array and the model will assess test impact as unknown rather than hallucinating. The output schema is designed to be parsed by your CI pipeline: use safe_to_apply as the primary gate, recommendation for routing, and review_notes for the human reviewer when escalation is required.

Before deploying this prompt into an automated pipeline, run it against a golden set of known-safe and known-unsafe diffs to calibrate your confidence thresholds. Pay special attention to false negatives—cases where the model marks an unsafe diff as safe. These are more dangerous than false positives. If your safety policy is complex, consider splitting it into a separate system instruction or injecting it as a structured JSON object rather than free text. Always log the full prompt, response, and decision to your audit trail so that every autofix application or rejection is traceable.

Integrating the Linter Autofix Safety Validation Prompt into a production workflow requires treating it as a deterministic safety gate, not a conversational suggestion. The prompt should be called after an autofix diff is generated but before it is applied to the working tree. The application layer is responsible for extracting the proposed diff from the linting tool or coding agent, assembling the required context (original source, lint rule metadata, test impact analysis), and passing it to the model. The model's structured output—specifically the safe_to_apply boolean, semantic_change_detected flag, and verification_steps list—must be parsed and enforced by the harness, not trusted as free-text advice.

The harness should enforce a strict output contract. Configure your model call with a JSON schema that requires safe_to_apply (boolean), risk_level (enum: low, medium, high, blocker), semantic_change_detected (boolean), side_effects (array of strings), style_regressions (array of strings), test_impact (object with affected_tests and recommended_action), and verification_steps (array of strings). If the model returns safe_to_apply: false or risk_level: blocker, the harness must block the autofix and route the finding for human review. For medium or high risk, the harness should require explicit approval from a reviewer before proceeding. Only low risk with safe_to_apply: true should be eligible for automated application. Log every decision with the full model response, the diff, and the lint rule ID for auditability.

Implement retry logic carefully. If the model fails to produce valid JSON, retry once with a stricter prompt that includes the parse error message. If the second attempt also fails, escalate to human review and log the failure. Do not retry more than twice—a model that cannot produce valid structured output on a safety-critical task should not be trusted with automated decisions. For model selection, prefer models with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller or faster models for this task unless you have validated their performance on a golden dataset of known safe and unsafe autofix diffs. The cost of a false negative (applying a breaking change) far outweighs the latency savings of a smaller model.

Before deploying, build a regression test suite with at least 20 curated examples: 10 diffs that should be marked safe, 5 that introduce subtle semantic changes (e.g., changing operator precedence, altering loop bounds, modifying exception handling), and 5 that cause style regressions or side effects. Run these through the harness and measure precision and recall on safe_to_apply decisions. Set a minimum pass threshold (e.g., 95% recall on unsafe diffs—you must not miss a breaking change). Integrate these tests into your CI pipeline so that any change to the prompt template, model version, or output schema triggers a re-evaluation. If you are operating in a regulated industry or on safety-critical code (e.g., medical device firmware, aviation systems, payment processing), add a mandatory human review step for every autofix regardless of the model's risk assessment, and retain all decision logs as compliance evidence.