github-dependabot

Fix Dependabot Alerts

Use gh api to get live alert data, then make the smallest safe dependency changes that resolve the current open alerts.

Workflow

1. Establish the repository context

1. Read AGENTS.md and the instructions for every affected project.
2. Inspect git status --short and the relevant diffs. Preserve unrelated user changes.
3. If GitHub access fails, run gh auth status. Treat 403 and 404 responses as possible permission or feature-availability problems, not proof that the repository has no alerts. Do not change authentication or repository settings without the user's approval.

2. Fetch the current alerts

Always query GitHub at the start of the task. Treat "latest alerts" as the current open alerts unless the user gives a narrower scope.

gh api --paginate -X GET \
  'repos/{owner}/{repo}/dependabot/alerts' \
  -f state=open \
  -f sort=created \
  -f direction=desc \
  -f per_page=100 \
  --jq '.[] | {
    number,
    created_at,
    updated_at,
    package: .dependency.package.name,
    ecosystem: .dependency.package.ecosystem,
    manifest: .dependency.manifest_path,
    scope: .dependency.scope,
    severity: .security_advisory.severity,
    ghsa: .security_advisory.ghsa_id,
    cve: .security_advisory.cve_id,
    vulnerable_range: .security_vulnerability.vulnerable_version_range,
    patched_version: .security_vulnerability.first_patched_version.identifier,
    url: .html_url
  }'

Keep --paginate; repositories can have more than one page of alerts. If the user asks for only the newest alert, select the first result. Otherwise, address every open alert in scope.

Fetch complete data for an individual alert when necessary:

gh api -X GET 'repos/{owner}/{repo}/dependabot/alerts/<number>'

Do not dismiss alerts or change their state through the API. GitHub closes resolved alerts after it processes the updated dependency graph.

3. Plan the dependency changes

1. Group alerts by ecosystem, manifest, and package. One dependency update can resolve more than one advisory.
2. Record each alert number, vulnerable range, first patched version, and affected manifest before editing.
3. Locate the canonical version declaration. In this repository, check pnpm-workspace.yaml catalogs and overrides before changing individual package.json files.
4. For a transitive dependency, use the ecosystem's dependency-inspection command to find which direct dependency introduces it. Prefer updating that direct dependency. Add or change an override only when a direct update cannot resolve the advisory safely and the repository already supports that mechanism.
5. Choose the smallest compatible version that satisfies every patched-version floor for the grouped alerts. Avoid unrelated major-version or toolchain upgrades unless the security fix requires them.
6. If GitHub reports no patched version, investigate whether upgrading or removing the introducing dependency resolves the vulnerable range. Do not invent a safe version or conceal an unresolved alert.