Monorepo Affected Test Detection Prompt Template

This prompt is designed for build engineers and SDETs working in monorepo environments who need to determine which tests to run based on a set of code changes. Instead of executing the entire test suite, which can take hours, this prompt analyzes shared dependency changes, package.json or build file diffs, and cross-package import graphs to produce a targeted test selection. Use this prompt when you have a git diff, a dependency graph representation, and a test-to-package mapping. The output is a structured test selection with impact rationale, a build graph summary, and a parallelization recommendation.

The ideal input is a structured diff of changed files, a machine-readable dependency graph (e.g., a JSON representation of your Nx, Turborepo, or Bazel project graph), and a mapping of test suites to the packages or modules they cover. The prompt works best when the dependency graph includes explicit dependsOn relationships and the test mapping is granular enough to distinguish unit, integration, and end-to-end test suites. You should also provide a runtime budget or a maximum parallelism constraint so the model can produce a realistic execution plan rather than an unbounded recommendation.

This prompt is not a replacement for a dedicated build system plugin like Nx Affected or Turborepo's --filter flag. It is a decision-support tool that produces auditable selection logic you can feed into your CI orchestrator. Do not use this prompt when the dependency graph is incomplete, when test-to-package mappings are missing or stale, or when the change set includes infrastructure-as-code modifications that require environment-level validation outside the package graph. In high-risk regulated environments, always require a human to review the selection rationale and confirm that no safety-critical tests were excluded before proceeding with a reduced test run.

This prompt template is designed to be the core instruction set you provide to a capable large language model. It forces the model into the role of a build engineer with specific expertise in monorepo tooling and test architecture. The template uses square-bracket placeholders that you must replace with real data from your CI environment, version control system, and build graph before execution. The primary goal is to transform raw change data into a structured, risk-aware test plan that can be consumed by downstream automation.

codeCopy
You are a senior build engineer specializing in monorepo management and test optimization. Your task is to analyze the provided code changes and produce a structured test selection plan. You must reason about shared dependencies, cross-package imports, and build graph impacts.

## INPUT DATA
- Changed Files Diff: [GIT_DIFF_OUTPUT]
- Dependency Graph (JSON): [DEPENDENCY_GRAPH_JSON]
- Build File Diffs (e.g., package.json, Cargo.toml): [BUILD_FILE_DIFFS]
- Historical Test Data (flake rates, avg duration): [HISTORICAL_TEST_DATA_JSON]

## OUTPUT SCHEMA
You must respond with a single valid JSON object conforming to this structure:
{
  "test_selection": [
    {
      "test_suite_name": "string",
      "selection_rationale": "string (e.g., 'direct dependency change', 'transitive import affected')",
      "priority": "high | medium | low",
      "estimated_duration_seconds": number
    }
  ],
  "skipped_tests": [
    {
      "test_suite_name": "string",
      "skip_rationale": "string (e.g., 'no dependency path to changed files')",
      "risk_of_skip": "low | medium"
    }
  ],
  "build_graph_impact_summary": "string (a concise summary of the blast radius)",
  "parallelization_recommendation": {
    "groups": [["suite_a", "suite_b"], ["suite_c"]],
    "rationale": "string (explain grouping based on dependency constraints)"
  }
}

## CONSTRAINTS
- Do not select tests that have no dependency path to the changed files.
- If a shared library is changed, you must include all direct dependents in the high-priority selection.
- Account for transitive dependencies up to a depth of [TRANSITIVE_DEPTH_LIMIT].
- If historical data shows a test is flaky (failure rate > [FLAKE_THRESHOLD]%), flag it in the rationale but still include it if it is a direct dependent.
- The total estimated duration of selected tests should not exceed [MAX_TEST_RUNTIME_MINUTES] minutes unless the high-priority selection alone exceeds it.
- Base all decisions strictly on the provided input data. Do not hallucinate file paths or dependencies.

To adapt this prompt, start by integrating it into your CI/CD pipeline script. Replace [GIT_DIFF_OUTPUT] with the actual diff between the feature branch and the main branch. The [DEPENDENCY_GRAPH_JSON] should be generated by your monorepo tool (e.g., Nx, Turborepo, Bazel) and formatted as a JSON object where keys are project names and values are arrays of their dependencies. For [BUILD_FILE_DIFFS], extract only the changes to manifest files like package.json to help the model understand dependency version shifts. Finally, tune [TRANSITIVE_DEPTH_LIMIT] and [FLAKE_THRESHOLD] based on your team's risk tolerance; a depth of 2 and a threshold of 5% are common starting points. The output JSON can be directly parsed by a subsequent script to dynamically set the test matrix for your CI runner.

This prompt is designed to run as a gate in your CI/CD pipeline after dependency changes are detected but before a full test suite execution. The typical integration point is a GitHub Actions workflow, Jenkins pipeline, or Buildkite step that triggers on pull requests or merges to main. The prompt consumes a structured diff of changed files, a dependency graph extracted from your monorepo's package manifests (e.g., package.json, Cargo.toml, build.gradle), and an optional test-to-module mapping file. The output is a JSON test selection plan that your test orchestrator reads to decide which test targets to execute and in what order.

Validation and retry logic is critical because an incorrect test selection can skip tests that would have caught a regression. Implement a JSON schema validator that checks the output for required fields: affected_modules, selected_tests, excluded_tests_with_rationale, parallelization_groups, and confidence_score. Each excluded test must include a rationale string and a risk_level enum (low, medium, high). If validation fails, retry the prompt once with the validation errors appended to the [CONSTRAINTS] block. If the second attempt also fails validation, fall back to running the full test suite and log an alert to your observability platform. For high-risk repositories (e.g., payment processing, auth services), configure a human approval step when the confidence_score falls below 0.85 or when any excluded test carries a high risk_level.

Model choice and latency matter in CI pipelines where developers are waiting. Use a fast model (e.g., Claude 3.5 Haiku, GPT-4o-mini) for the initial selection pass. Reserve larger models for the fallback retry path. Cache the dependency graph and test mapping files as pipeline artifacts to avoid regenerating them on every run. The prompt's [INPUT] should be a pre-computed JSON object containing changed_files, dependency_graph, and test_module_map—do not pass raw file contents or git diffs directly. Build a preprocessing step that parses your monorepo's package manifests and produces a normalized dependency graph with explicit depends_on and used_by edges. This preprocessing is the most common failure point: if the graph is incomplete, the prompt will produce a plausible but incorrect test selection. Validate the graph's completeness by checking that every changed file maps to at least one module in the graph before invoking the prompt.

Logging and auditability are non-negotiable for compliance and incident review. Log the full prompt input, output, validation result, retry count, and final test selection decision to your CI artifacts or a dedicated audit store. Include a selection_id UUID in the output that ties the prompt's decision to the specific pipeline run. When a defect escapes to production, this audit trail lets you trace whether the prompt excluded the relevant test and why. Wire the output into your test reporting dashboard so teams can see which tests were skipped and the stated rationale. Finally, run a weekly eval sweep using historical commits where you know which tests should have been selected—compare the prompt's recommendations against ground truth and track precision/recall over time. Degradation in these metrics is your signal to update the dependency graph extraction logic or adjust the prompt's risk thresholds.