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 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?"
• PR title contains dependency update patterns (e.g. chore(deps):, fix(deps):, bump, update)
• User shares a PR URL for a dependency update

When not to use

• 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:

• Repository owner and name
• PR number or URL, or a copied PR summary including package name, version change, changed files, and CI status
• Optional: specific review concerns or areas of focus

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

If 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 user choose.
• Keep shortlist concise: 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:

1. Run agents/target-pr-advisor.md first when the PR target is missing or ambiguous so the review starts from one explicit dependency PR.
2. Run agents/research-advisor.md to normalize the PR context, existing discussion, source list, and research notes.
3. 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

4. Chain the combined research and lens outputs into agents/verdict-advisor.md for recommendation, confidence, handoff, and confirmation wording.
5. 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

1. Resolve target PR with agents/target-pr-advisor.md and concise prompts in references/questions.md.
2. Gather context and build shared evidence packet with agents/research-advisor.md, assets/review-tracker.md, and assets/research-template.md.
3. Run agents/security-advisor.md, agents/code-quality-advisor.md, and agents/impact-advisor.md in parallel with the same normalized research packet.
4. Use agents/verdict-advisor.md to produce recommendation, confidence, follow-up, and explicit maintainer prompt.
5. Use agents/source-control-advisor.md only after verdict is accepted and only when branch work is required.
6. Follow references/instructions.md for 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

• This skill is mutation-capable. Repository-local workflow instructions take precedence over inline guidance when they conflict.

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 — this includes PR metadata, changed files, CI status, and existing discussion
• Do not re-fetch PR comments or review threads independently in each advisor; pass the pre-fetched data from the research advisor to all lens advisors
• 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