Edit Impact Scope Analysis Prompt

This prompt is for coding agents that must estimate the blast radius of a proposed edit before making any changes. It produces a dependency graph traversal report listing affected callers, importers, tests, and configuration files. Use it as a pre-edit gate in automated refactoring pipelines, CI-integrated code review, or any workflow where an agent proposes a change and the system needs a risk assessment before granting write access. The prompt assumes the agent has access to repository structure, symbol resolution, and dependency graph data. It does not replace static analysis tools but adds a reasoning layer that explains why specific files are in the blast radius.

This prompt belongs in the Safe File Modification and Edit Verification workflow, immediately after a change is proposed and before any file is touched. The ideal user is a platform engineer or AI tooling developer building an automated coding agent harness. The agent should already have resolved the target symbol, gathered its callers and importers, and assembled a dependency graph snapshot. Feed that structured context into the prompt along with the proposed edit description and a risk tolerance level. The output is a structured report you can parse to decide whether to proceed, request human review, or reject the edit. Wire the report into a gating function that blocks file writes when the blast radius exceeds a configured threshold or touches protected paths like production configuration or generated code.

Do not use this prompt when the agent lacks dependency graph data, when the proposed edit is purely cosmetic and confined to a single line with no imports, or when you need byte-level precision about runtime behavior. This prompt reasons about static dependencies, not dynamic dispatch, reflection, or runtime plugin systems. For high-risk repositories, always pair the blast radius report with a human-in-the-loop approval step. The next step after generating this report is to feed it into an Edit Safety Checklist or a Multi-File Edit Consistency Check before any file modification begins.

This prompt template is designed for a coding agent that has already assembled the necessary context: the proposed change description, a dependency graph of the repository, and a list of files in the change's scope. It instructs the model to act as a static analysis engine, tracing the impact of the change through the dependency graph to identify all potentially affected components. The output is a structured report, not the code change itself, enabling a risk assessment before any file is modified.

textCopy
You are a codebase impact analysis engine. Your task is to estimate the blast radius of a proposed code change.

You are provided with the following context:
- [PROPOSED_CHANGE_DESCRIPTION]: A natural language description of the code modification being considered.
- [DEPENDENCY_GRAPH]: A structured representation of the repository's dependencies, including function calls, imports, class inheritance, and data flow.
- [SCOPE_FILES]: A list of file paths that are the primary targets of the proposed change.

Analyze the proposed change and generate a structured impact report. For each file in [SCOPE_FILES], trace its dependents (callers, importers, subclasses) and dependencies (callees, imports, parent classes) using the [DEPENDENCY_GRAPH].

Your report must be a JSON object conforming to this schema:
{
  "affected_components": [
    {
      "file_path": "string",
      "component_name": "string",
      "impact_type": "DIRECT_TARGET | DIRECT_DEPENDENCY | INDIRECT_DEPENDENCY | CONFIGURATION",
      "impact_reason": "A concise explanation of the dependency path from the change to this component.",
      "risk_level": "HIGH | MEDIUM | LOW"
    }
  ],
  "affected_tests": [
    {
      "test_file_path": "string",
      "test_name": "string",
      "likely_impact": "LIKELY_FAIL | MAYBE_BREAK | UNLIKELY_AFFECTED",
      "reasoning": "Explanation of how the change could affect this test's logic or setup."
    }
  ],
  "configuration_impact": [
    {
      "config_file_path": "string",
      "config_key": "string",
      "required_action": "UPDATE | REVIEW | NO_CHANGE",
      "reasoning": "Why this configuration might need attention."
    }
  ],
  "overall_risk_assessment": {
    "risk_score": "HIGH | MEDIUM | LOW",
    "summary": "A one-paragraph summary of the total blast radius and the primary risk drivers."
  }
}

Adhere to these constraints:
- [CONSTRAINTS]: Only report components and files that have a verifiable dependency path from the proposed change. Do not speculate. If the dependency graph is incomplete, note this in the summary and flag affected components with MEDIUM risk. Do not suggest fixes or implementation details.

To adapt this prompt, replace the square-bracket placeholders with data from your agent's context-gathering phase. The [PROPOSED_CHANGE_DESCRIPTION] should be a precise, single-sentence summary of the edit. The [DEPENDENCY_GRAPH] can be a JSON object, a list of source -> target relationships, or a serialized adjacency list. The [CONSTRAINTS] placeholder is critical for safety; always include a rule to ground the analysis strictly in the provided graph data to prevent hallucinated dependencies. For high-risk repositories, add a constraint requiring the model to flag any component where the dependency path is ambiguous and recommend manual review.

The Edit Impact Scope Analysis prompt is designed to run before any file modification in an agent loop. It should be wired as a synchronous pre-flight check that gates the actual edit operation. The agent's orchestration layer calls this prompt with the proposed edit target and the repository context, then parses the structured dependency graph from the response. If the blast radius exceeds a configurable threshold—such as more than N affected callers, test files, or configuration dependencies—the agent should either request human approval or switch to a safer edit strategy like a dry-run simulation.

For implementation, wrap the prompt in a function that accepts [TARGET_FILE], [PROPOSED_CHANGE_DESCRIPTION], and [REPOSITORY_CONTEXT] as inputs. The repository context should be assembled from tool outputs: a git grep for importers and callers, a dependency graph query from your language server or build system, and a test file mapping. Pass these as structured context rather than raw dumps. The model should return a JSON schema with fields: affected_files (list of paths with reason codes), affected_tests (test files that exercise changed code paths), affected_configs (configuration or environment files), risk_level (low/medium/high/critical), and recommended_verification_steps. Validate the response against this schema immediately. If parsing fails, retry once with a stricter schema reminder. If it fails again, escalate to a human with the raw response and the proposed edit.

For eval and observability, log every impact analysis result alongside the eventual edit outcome. Build a feedback loop: compare the predicted affected files against what actually broke in CI or production after the edit landed. Track precision (did we flag files that didn't actually need changes?) and recall (did we miss files that broke?). Use these metrics to tune the risk threshold for human review. For high-risk repositories—production services, shared libraries, security-critical code—always require human approval when risk_level is high or critical, regardless of other metrics. The prompt is a decision-support tool, not a decision-maker. Wire it to inform, not to automate the final go/no-go call on dangerous edits.