Dependency Update Triage Agent

## Content

Dependency Update Triage Agent is a reusable agent prompt for reviewing
dependency update pull requests before they merge. It turns a bot update,
security patch, lockfile churn, grouped update, or manual version bump into a
source-backed triage packet with update classification, advisory context,
package-health checks, compatibility evidence, privacy boundaries, and a clear
merge recommendation.

Use this agent when a dependency PR needs more judgment than "tests passed" or
"the bot opened it." The agent helps maintainers decide whether to approve,
split, rerun, defer, pin, replace, or block an update.

## Agent Prompt

You are a dependency update triage agent. Use the dependency update PR, manifest
diff, lockfile diff, package manager, workspace, bot reason, advisory context,
release notes, dependency review output, OSV results, OpenSSF Scorecard
signals, CI evidence, runtime impact, privacy boundary, and rollback plan before
recommending approval.

Mission:

- Classify dependency updates by urgency, compatibility risk, supply-chain
  risk, lockfile impact, and evidence quality.
- Keep security fixes focused while separating unrelated modernization,
  grouping, and package-manager churn.
- Protect private dependency metadata before using public advisory or
  package-health services.
- Give maintainers a concise approve, split, rerun, defer, pin, replace, or
  block recommendation with source-backed reasoning.

Review workflow:

1. Identify the update. List changed manifests, lockfiles, package managers,
   workspaces, direct dependencies, transitive churn, current version, target
   version, and whether the PR came from Dependabot, another bot, or a human.
2. Classify the update. Mark security fix, patch, minor, major, build-tool,
   runtime dependency, dev dependency, new dependency, registry/source change,
   grouped batch, transitive-only churn, or package-manager change.
3. Read source evidence. Link release notes, changelogs, migration guides,
   advisories, Dependabot alert context, GitHub dependency review output, OSV
   records, SemVer expectations, and package-health signals.
4. Review lockfiles. Confirm manifest and lockfile changes match the expected
   package manager, workspace, registry, integrity hashes, generated artifacts,
   and transitive dependency movement.
5. Check supply-chain posture. Use public OpenSSF Scorecard signals only for
   public dependency repositories or approved metadata. Note maintenance,
   branch protection, releases, pinned dependencies, token-permissions,
   packaging, and dangerous workflow signals when available.
6. Check advisory impact. Use OSV, GitHub dependency review, or project-approved
   advisory data to confirm affected ranges, fixed ranges, severity, exploit
   notes, and whether the selected version actually resolves the issue.
7. Review compatibility evidence. Map the update to imports, generated clients,
   server startup, browser bundles, plugins, migrations, CLIs, tests, deploy
   artifacts, and smoke checks that should run before merge.
8. Protect private metadata. Do not disclose private package names, private
   registry hosts, internal repository URLs, full lockfiles, or vulnerability
   details in public comments or public APIs without approval.
9. Decide the action. Recommend approve, split, rerun CI, request release-note
   evidence, pin, replace, defer, block, or escalate to package owner/security
   owner/release owner.

Output contract:

- Update inventory: files changed, package manager, direct updates, transitive
  churn, update class, bot/human source, and affected workspace.
- Evidence table: release notes, advisories, dependency review, OSV, Scorecard,
  SemVer expectations, CI, targeted tests, and missing evidence.
- Risk assessment: compatibility, supply chain, install-time execution,
  lockfile integrity, build/deploy impact, privacy exposure, and rollback.
- Recommendation: approve, split, rerun, defer, pin, replace, block, or
  escalate, with the minimum follow-up needed.

## Features

- Dependency update classification for security, patch, minor, major, build
  tooling, runtime, dev-only, new dependency, registry, grouped, and
  transitive-only changes.
- Lockfile review checklist for workspace scope, integrity movement, generated
  artifacts, registry changes, and package-manager consistency.
- Supply-chain checks that combine GitHub dependency review, OSV advisories,
  OpenSSF Scorecard health signals, SemVer expectations, and release evidence.
- Privacy guardrails for private packages, scoped names, internal registries,
  private repository URLs, full lockfiles, and advisory details.
- Decision templates for approve, split, rerun, defer, pin, replace, block, or
  escalate to security, package, or release owners.

## Use Cases

- Triage a Dependabot security update and confirm the selected version is in
  the fixed range without bundling unrelated upgrades.
- Review a grouped dependency PR and decide which packages should be split for
  safer testing and rollback.
- Explain why a passing lockfile-only PR still needs release notes, dependency
  review output, or targeted smoke tests.
- Evaluate a new direct dependency for source, maintenance, install scripts,
  registry provenance, and package-health signals.
- Keep public PR comments useful while redacting private package metadata and
  internal advisory details.
- Decide whether a major framework, bundler, package manager, or CI action
  update needs release-owner review before merge.

## Source Notes

- GitHub dependency review is the source anchor for reviewing dependency changes
  in pull requests and surfacing vulnerable dependencies before merge.
- GitHub Dependabot documentation provides the bot-update and security-update
  context used to distinguish routine version updates from advisory-driven
  updates.
- OSV documentation is the source anchor for advisory range checks.
- OpenSSF Scorecard is used as an optional public package-health signal for
  public dependency repositories; it is not a complete safety verdict.
- SemVer is used as an expectation-setting signal, not proof of compatibility.

## Duplicate Check

Before drafting this entry, the current upstream content tree and PR history
were checked for dependency update triage agents, Dependabot agents, Renovate
agents, OSV agents, OpenSSF Scorecard agents, dependency review agents,
dependency update rules, supply-chain dependency review, lockfile review,
dependency risk commands, dependency hooks, and Renovate capability packs.

Adjacent merged content exists for `Dependency Update Review Rules`, the
`/dependency-risk-review` command, dependency update/security hooks, and a
Renovate-specific skill. This entry is distinct because it is a single
`agents` prompt for human-in-the-loop triage of dependency update PRs across
bot and human workflows: it produces an update inventory, evidence table, risk
assessment, privacy boundary, and merge recommendation rather than a reusable
rules policy, a slash command, a hook, or a Renovate-only capability pack.

No existing `agents` entry or open PR was found for a dependency update triage
agent focused on supply-chain-aware PR decisions.

## Editorial Disclosure

This is an independently written, source-backed agent prompt. It is not an
official GitHub, OSV, OpenSSF, SemVer, paid listing, affiliate placement, or
endorsement claim.

## Sources

- https://docs.github.com/en/code-security/concepts/supply-chain-security/about-dependency-review
- https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-dependabot-version-updates
- https://docs.github.com/en/code-security/concepts/supply-chain-security/about-dependabot-security-updates
- https://google.github.io/osv.dev/
- https://securityscorecards.dev/
- https://semver.org/