Dependency Graph Impact Analysis Prompt for Test Prioritization

This prompt is designed for test architects and SDETs who need to convert a known module dependency graph and a set of recent code changes into a defensible, risk-prioritized test execution order. The core job-to-be-done is reducing the feedback loop for propagation failures: when module A changes, you need to know whether to run tests for module A first, or if downstream module B carries a higher risk of a transitive break. Use this when you have a structured representation of your system's dependencies (e.g., a JSON or DOT graph), a list of modified modules from a diff or changelist, and a mapping of test suites to the modules they cover. The prompt's value is in making the prioritization rationale explicit and auditable, not just producing a list of tests.

This prompt is most effective inside a risk-based test selection workflow where a human or an automated system will review the reasoning before committing to a reduced test suite. You should not use this prompt when you lack a reliable dependency graph, when the graph is too coarse (e.g., only top-level services without internal module boundaries), or when test-to-module mappings are incomplete. It is also not a replacement for a full CI/CD pipeline that runs all tests on a merge to main; it is a tool for pre-merge or pre-release risk assessment where execution time is constrained and you must justify which tests to skip. The prompt assumes you can provide the dependency graph as structured data—if your architecture is undocumented, invest in generating that graph first through static analysis or build tooling before applying this prompt.

Before using this prompt, ensure you have defined a maximum transitive depth for impact analysis. Without a depth limit, a change in a leaf utility module can theoretically propagate to every test in the system, making the output useless. A typical starting point is a depth of 2 or 3, which you can tune based on your system's coupling characteristics. Also, prepare a validation step for circular dependencies: the prompt includes instructions for handling them, but you should verify that the model's resolution matches your architectural reality. Finally, treat the output as a recommendation, not an automated gate. In high-risk domains like finance or healthcare, always require a human to sign off on any skipped tests, and log the prompt's rationale alongside the final execution order for auditability.

This prompt template is the core instruction set you will send to the model. It is designed to be self-contained: paste it into your AI system, replace the square-bracket placeholders with your actual data, and run it. The template forces the model to reason about upstream change propagation, circular dependencies, and transitive impact depth before producing a ranked test list. It also requires explicit validation rules and a structured output schema, making the result auditable and machine-readable.

textCopy
You are a test architect analyzing a software module dependency graph to prioritize regression tests after a code change. Your goal is to produce a risk-prioritized test execution order based on upstream change propagation risk.

## INPUT
- Dependency Graph: [DEPENDENCY_GRAPH]
- Changed Modules: [CHANGED_MODULES]
- Available Test Suites: [TEST_SUITES]
- Historical Failure Data (optional): [FAILURE_DATA]
- Max Transitive Depth: [MAX_DEPTH]

## CONSTRAINTS
- Handle circular dependencies by treating the cycle as a single risk unit and flagging it.
- Do not exceed the specified Max Transitive Depth when tracing impact.
- If a module has no tests, flag it as an untested risk.
- Justify every prioritization decision with a specific dependency path.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "analysis_summary": "string",
  "circular_dependencies_detected": [
    {
      "cycle": ["module_a", "module_b"],
      "risk_note": "string"
    }
  ],
  "untested_modules": ["module_x"],
  "prioritized_test_order": [
    {
      "rank": 1,
      "test_suite": "string",
      "target_module": "string",
      "risk_score": 0.0-1.0,
      "rationale": "string (include dependency path)",
      "transitive_depth": 0
    }
  ],
  "validation_notes": ["string"]
}

## INSTRUCTIONS
1. Parse the dependency graph and identify all modules directly or transitively dependent on the changed modules, up to the Max Transitive Depth.
2. For each affected module, calculate a risk score based on: proximity to the change, historical failure rate (if provided), and the number of dependent modules.
3. Map affected modules to the available test suites.
4. Sort test suites by risk score in descending order.
5. Validate your output: check for missing dependencies, depth limit violations, and circular dependency handling.
6. Return the JSON.

To adapt this template, replace the placeholders with your real data. [DEPENDENCY_GRAPH] should be a structured representation of your modules and their dependencies—a JSON adjacency list, a Mermaid diagram, or a simple A -> B, B -> C text format. [CHANGED_MODULES] is a list of module names that were modified. [TEST_SUITES] is a mapping of test suites to the modules they cover. [MAX_DEPTH] is an integer (e.g., 3) that limits how far the model traces transitive dependencies to prevent analysis paralysis on very large graphs. If you have historical failure data from your test management system, include it in [FAILURE_DATA] to improve risk scoring accuracy.

Before integrating this prompt into a CI/CD pipeline, test it against a known, small dependency graph where you can manually verify the expected output. Pay close attention to how the model handles cycles and depth limits—these are the most common failure points. For high-risk releases, always have a test architect review the prioritized list before execution begins. The structured JSON output is designed to be consumed by a downstream test runner, so validate the schema strictly before automation.

The dependency graph impact analysis prompt is designed to be called programmatically within a CI/CD or test orchestration pipeline, not as a one-off chat interaction. The application layer is responsible for assembling the dependency graph, the change list, and the test catalog before invoking the model. The prompt expects these structured inputs and returns a prioritized test list with risk justifications. The harness must validate the output against the known test inventory to prevent hallucinated test IDs, enforce the transitive impact depth limit, and flag any circular dependency claims that contradict the input graph.

Wire the prompt into your pipeline by first constructing a JSON payload containing the [DEPENDENCY_GRAPH] (nodes and directed edges), [CHANGED_MODULES] (list of modified components), [TEST_CATALOG] (all available tests with their module coverage), and [CONSTRAINTS] (max depth, time budget, risk thresholds). After receiving the model response, run a strict post-processing validator: (1) confirm every recommended test ID exists in the input catalog, (2) verify that the transitive_depth field for each test does not exceed the configured limit, (3) check that no circular dependency is claimed unless it is present in the input graph, and (4) ensure the output conforms to the expected JSON schema. If validation fails, retry once with a repair prompt that includes the specific validation errors. If the retry also fails, log the failure, fall back to a rule-based selection (e.g., all tests for changed modules plus one hop), and alert the on-call channel.

Model choice matters here. Use a model with strong structured output capabilities and a large context window if your dependency graph is extensive. For production, prefer a model that supports strict JSON mode or function calling to reduce parsing errors. Log every invocation with the input graph hash, change list, model version, raw output, validation results, and final test execution order. This audit trail is essential for post-incident review and for tuning the prompt's risk thresholds over time. Avoid using this prompt for real-time commit-gate decisions without a human review escape hatch for high-risk releases where the blast radius exceeds a pre-defined threshold.