Dependency Review

Structured review workflow for dependency update PRs. Produces consistent research notes that incorporate existing PR discussion, multi-lens analysis, and an actionable verdict with explicit maintainer confirmation before any merge action.

When to use

Use this skill when a dependency PR needs review and you want a consistent, auditable decision process.

Typical triggers:

"Review this dependency PR"
"Should we merge this dependency update?"
"Check this Renovate/Dependabot PR"
"Review one of our open dependency PRs"
"What changed in this library bump?"
"Is this dependency update safe to merge?"
A PR title contains dependency update patterns (for example chore(deps):, fix(deps):, bump, update)
The user shares a PR URL for a dependency update

When not to use

Do not use this skill for:

Feature PRs or application code reviews (use standard code review workflows)
Dependency automation or bot configuration
Approving/merging without explicit user confirmation
Deciding organizational dependency policy

Required inputs

Collect before starting the review:

Repository owner and name
PR number or URL for the dependency update, or a copied PR summary that includes package name, version change, changed files, and CI status
Optional: specific review concerns or areas of focus from the maintainer

If required details are missing, ask concise clarifying questions from references/questions.md.

If the PR target is missing or ambiguous:

Ask only the minimal follow-up question needed to identify the target PR.
When repository context is known, use GitHub MCP to list likely open dependency PRs and let the user choose instead of guessing.
Keep the shortlist concise and decision-friendly: include PR number, title, dependency/package hint, author, and CI state when available.

Auto-extract from the PR when available:

Package(s) being updated and version range (from → to)
Changelog/release notes URL
CI status
Changed files and dependency ecosystem
Existing top-level PR comments, review comments, and unresolved thread state

Instructions

Preferred advisor orchestration

When the runtime supports skill-local advisors, prefer this execution shape instead of a single long linear pass:

Run agents/target-pr-advisor.md first when the PR target is missing or ambiguous so the review starts from one explicit dependency PR.
Run agents/research-advisor.md to normalize the PR context, existing discussion, source list, and research notes.
Fan out the lens advisors in parallel with the same normalized inputs:

agents/security-advisor.md
agents/code-quality-advisor.md
agents/impact-advisor.md

Chain the combined research and lens outputs into agents/verdict-advisor.md for recommendation, confidence, handoff, and confirmation wording.
Chain into agents/source-control-advisor.md only if the accepted next step requires PR patching, rebase, conflict resolution, or merge-readiness work.

Keep the lens advisors narrow and independent. The parent skill owns the unified review and should preserve disagreement between advisors instead of flattening it early.

Workflow summary

Resolve the target PR with agents/target-pr-advisor.md and the concise prompts in references/questions.md.
Gather context and build the shared evidence packet with agents/research-advisor.md, assets/review-tracker.md, and assets/research-template.md.
Run agents/security-advisor.md, agents/code-quality-advisor.md, and agents/impact-advisor.md in parallel with the same normalized research packet.
Use agents/verdict-advisor.md to produce the recommendation, confidence, follow-up, and explicit maintainer prompt.
Use agents/source-control-advisor.md only after the verdict is accepted and only when branch work is required.
Follow references/instructions.md for the detailed live-PR contract: target selection, checkpoint comments, decision gates, and handoff timing.

Assets

assets/research-template.md: research-comment structure for change summary, breaking changes, known issues, and sources
assets/verdict-template.md: verdict structure for lens assessments, recommendation, confidence, and follow-up items
assets/review-tracker.md: working checklist and tracker for context, validation, lens outcomes, and handoff decisions

References

references/instructions.md: detailed execution contract for target selection, live-PR checkpoints, and decision sequencing
references/questions.md: concise follow-up questions for choosing the target dependency PR and scoping the review

Advisors

agents/target-pr-advisor.md: resolves the exact dependency PR to review or returns a shortlist for user selection
agents/research-advisor.md: first pass; builds the shared evidence packet for all later advisors
agents/security-advisor.md: parallel lens pass; checks security posture and attack-surface changes
agents/code-quality-advisor.md: parallel lens pass; checks upstream stability, regressions, and API drift
agents/impact-advisor.md: parallel lens pass; checks repository blast radius, CI, and follow-up work
agents/verdict-advisor.md: chained synthesis pass; turns research and lens outputs into one decision
agents/source-control-advisor.md: conditional final pass; handles rebase, sync, validation reruns, and push safety when patching the PR

If helper advisors are unavailable, follow the same orchestration inline: research first, lenses next, verdict after that, and source-control last only when mutation is needed.

Expected output

If the PR target is unresolved, return:

A concise shortlist of candidate dependency PRs when live PR search is available
The minimal follow-up question required to let the user choose the correct PR
Explicit status: Awaiting user PR selection

If the PR target is resolved, return a structured review containing:

Package name, version change, and update type
Existing PR discussion summary (top-level comments, review-thread themes, unresolved concerns)
Research summary (changelog highlights, breaking changes, known issues)
Security assessment with evidence
Code quality assessment with evidence
Impact assessment with evidence
Verdict: recommendation, rationale, confidence, and follow-up items
Handoff recommendation when follow-up work should become a tracked issue
Explicit action prompt for the maintainer

Safety & constraints

Never:

Merge or approve a dependency PR without explicit user confirmation
Create a merge commit by merging the base branch into a Dependabot or Renovate PR branch
Guess which PR to review when multiple plausible dependency PRs exist
Skip the research checkpoint comment or final verdict comment on a live PR
Ignore existing reviewer concerns because they are inconvenient or duplicative
Claim CI passed or security is clear without checking actual status
Expose secrets or tokens in comments or logs
Dismiss security concerns for convenience
Fabricate changelog entries or version details not found in sources

Always:

Ask minimal follow-up questions when the target PR is missing or ambiguous
Present evidence for each assessment (link to changelog, CVE, CI status)
List candidate dependency PRs for user selection when repository context exists but the PR target does not
Fetch existing PR comments and review threads via GitHub MCP before analysis on a live PR
Reuse one shared research packet across advisors instead of rediscovering the same facts in each pass
Prefer parallel lens analysis when the runtime supports it, then chain synthesis after all lens outputs are ready
Post the research checkpoint comment to the PR before any branch mutation on a live PR
Post the final verdict comment to the PR before any approval or merge on a live PR
Make branch-sync or rebase needs explicit before patching the PR
Rebase dependency PR branches onto the latest base branch when refresh is required; do not merge the base branch into the PR branch
Make follow-up work explicit rather than burying it in review notes
Respect the maintainer as the final decision-maker
Keep review output in a consistent, repeatable structure

fusion-dependency-review