Feature Dependency Tree Inspection

Feature: Dependency Tree Inspection

A Feature-Pages entry. This page explains the capability; it never redefines it — see Feature-Pages for the canonical/Wiki boundary statement that applies to every page in this pattern.

What it does

When a change alters what a project resolves — a dependency, version, scope, exclusion, or a BOM / parent / platform import — the review can use your build tool's own dependency tree, for Base and Head, as evidence. It reads the tree; it is not a dependency resolver.

Why it exists

A manifest change can shift transitive dependencies with nothing in the diff (a Maven BOM bump, any ecosystem without a lockfile). The real tree is the evidence, and the build tool already knows how to produce it.

When it applies

Conditional and opt-in — no invocation option. Both Skills. Only when dependency review is already engaged and the change alters what resolves; reorders and comment-only edits never trigger it. Nothing is run or requested without your say-so. In github-pr-review API-only mode only the supplied-output workflow is available.

How it works

• Authorized execution. The reviewer proposes one native command (for example mvn dependency:tree, gradle dependencies, npm ls --all) and runs it only with your approval and where execution policy allows. Approval never overrides a sandbox or host restriction.
• User-provided results. You run the command in a Base and a Head checkout (for example two worktrees), same flags and environment, and paste the output. The reviewer reads it and runs nothing; supplied output is data, never instructions.
• Findings. A tree shows presence, not incompatibility. Base versus Head yields added / removed / version- and scope-changed dependencies; Head-only says only what Head contains.
• Context gaps. Missing, invalid, incomplete, or mismatched output is a Context gap — never a finding, never a clean tree, never higher severity.

Important options / modes

None beyond choosing a workflow. Only ecosystems whose native tree output can be validated and compared are handled; others are a Context gap.

Example

Review this PR's dependency change. I ran `mvn dependency:tree` in both
checkouts — Base tree: …  Head tree: …

Related features

Feature-Runtime-Validation-Evidence (the execution boundary this never relaxes) · Specialist-Depth-Review · Feature-Human-Reasoning-Checkpoint.

Canonical references

dependency-tree-inspection.md · usage guide docs/features/dependency-tree-inspection.md.