Monorepo Impact Analysis Prompt: Map a Change's Blast Radius

A one-line change to a shared util in a monorepo can break four services or none. The diff doesn't tell you which. A monorepo impact analysis prompt does: feed it the change and a dependency list, and it returns the affected packages, the tests that actually cover the edit, and a blast radius ranked by risk.

The standard advice is to adopt Nx or Bazel and let the build graph compute affected targets. That's good advice if you've already paid the adoption cost. Most teams haven't. They're on a plain workspace with a package.json per package and no graph tooling, and they either run the entire test suite on every PR or guess at which tests matter. Both are wrong in different directions.

A prompt sits in that gap. It reasons about the blast radius from what you already have, a diff and a dependency manifest, without requiring you to migrate your build system first.

Why the diff alone lies about risk

A diff shows what changed. It says nothing about who depends on it. A two-character edit to a logging helper used by thirty packages is higher risk than a hundred-line change to a leaf nobody imports. Reading the diff in isolation inverts the risk picture exactly when it matters.

Here's the stance. Running the full test suite on every change isn't safety; it's a way to avoid thinking about the dependency graph. It feels thorough and it's slow enough that people start skipping it under deadline, which is when the real breaks ship. Targeted testing driven by an actual impact analysis is both faster and safer. The prompt's job is to make that targeting cheap enough that you'll actually do it.

What a monorepo impact analysis prompt does

A monorepo impact analysis prompt is a blast-radius reasoner that reads a diff plus a dependency list and returns affected packages, a minimal test set, and a risk ranking. It works without any build tool.

Use it to:

• Identify every package a diff touches, directly and transitively
• Separate direct dependents from transitive ones so reviewers see the surprises
• Recommend the minimal test set, no over-testing and no missed coverage
• Rank the blast radius by risk so the dangerous edit gets attention first
• Produce a structured impact report you can paste into the PR
• Flag changes to high-fan-in modules that warrant extra review

The transitive-versus-direct split is what catches the break a reviewer wouldn't expect.

Anatomy of the prompt

Variables
  {{change_diff}}        → the diff or branch reference
  {{dependency_list}}    → package → dependencies map
  {{test_inventory}}     → tests mapped to packages (optional)
  {{risk_weights}}       → what counts as high risk here (optional)

Prompt
  Role: you are a monorepo impact analyst.
  Task: from {{change_diff}} and {{dependency_list}}, compute
        the affected packages and blast radius.
  Rules:
    - Separate direct dependents from transitive.
    - Recommend the minimal test set, not the whole suite.
    - Rank affected packages by risk.

Output contract
  Return: affected-package table + test set + risk-ranked blast radius.

1. Capture the change

Put the diff or a branch reference in {{change_diff}}. A branch reference lets the prompt reason about a whole feature, not one commit.

2. Provide the dependency map

{{dependency_list}} is the spine of the analysis. Even a flat list of which package imports which gives the prompt enough to trace dependents.

3. Read the risk ranking

The output ranks affected packages by risk. The top of that list is where review and testing time should go.

4. Run the recommended tests

Instead of the full suite, run the minimal set the prompt returns. If it's a high-fan-in change, the prompt will say so and widen the set deliberately.

Prompt-craft patterns for impact analysis

Give the dependency list, not just the diff. The diff is half the input. Without {{dependency_list}}, the prompt can only see what changed, not who's downstream. The dependency map is what turns a diff into a blast radius.

Ask for direct and transitive separately. Collapsing them hides the dangerous case. A transitive dependent four hops away is exactly the break a reviewer won't anticipate, so it needs its own column.

Demand a minimal test set, not a suite. "Which tests should run" is the actionable output. A prompt that returns "run your tests" wasted the analysis. Force a named, scoped set.

Prompt-based analysis vs Nx and Bazel

A graph-aware build tool computes affected targets from real build metadata, so it's exact and fast at scale. A prompt reasons from a diff and a dependency list, so it's approximate but works on any repo today. They're not competitors as much as different points on a cost curve.

The honest tradeoff: if you're already on Nx, use its affected command and let a prompt summarize the result for the PR. If you're not, the prompt is the fastest path to targeted testing without a migration project. One caveat worth stating: a prompt's blast radius is only as good as the {{dependency_list}} you feed it. An incomplete list produces an incomplete analysis, and the prompt can't know what you didn't tell it. Keep the list current, or the risk ranking quietly understates the real surface.

Variables you'll set

Getting started

1. Copy the structure into your model.
2. Put your diff or branch in {{change_diff}}.
3. Supply the {{dependency_list}} so the prompt can trace dependents.
4. Run it and read the risk-ranked blast radius first.
5. Run the minimal test set it recommends, not the whole suite.
6. Paste the impact report into the PR for the reviewer.

To post the impact report straight to a PR or Slack with the dependency tracer and test selection already wired, the Monorepo Impact Analysis Agent Pack runs it end-to-end.

Impact analysis pairs naturally with the changes that trigger it. Before a sweeping transform, the Codemod Authoring Harness writes the AST transform itself. When a change alters a public API, the breaking change detection prompt tells you the semver impact on consumers. For staged upgrades across the same workspace, see the framework migration prompt, and for build-versus-buy, how to choose a reusable AI prompt pack.