Dependabot Security Plan

Dependabot Security Plan

Build a remediation plan from GitHub Dependabot security alerts. Each actionable fix becomes its own todo. Do not apply fixes unless the user asks after reviewing the plan.

Use gh for all GitHub operations.

Severity filter

GitHub API uses medium for Moderate. Ignore low unless the user explicitly asks for it.

Workflow

Dependabot Security Plan:
- [ ] 1. Resolve target repository
- [ ] 2. Fetch and filter open alerts
- [ ] 3. Keep only actionable fixes
- [ ] 4. Group and deduplicate
- [ ] 5. Investigate fix path per group
- [ ] 6. Build Plan with one todo per fix

Step 1: Resolve target repository

Determine {owner}/{repo} for the GitHub repository under review. This skill has no default repository — always resolve it at runtime.

Resolution order:

1. Explicit input from the user — any of:
   • owner/repo shorthand (e.g. acme/widget)
   • Full GitHub URL (e.g. https://github.com/acme/widget)
   • Dependabot security page URL (e.g. https://github.com/acme/widget/security/dependabot)
2. Current workspace — if the user does not name a repo, parse {owner}/{repo} from git remote get-url origin in the open workspace.

If ambiguous (multiple remotes, unclear shorthand, or no git remote), ask once. Do not guess across remotes or assume a repository from prior context.

Step 2: Fetch open alerts

gh api "repos/{owner}/{repo}/dependabot/alerts" --paginate \
  -q '.[] | select(.state=="open") | {
    number,
    severity: .security_advisory.severity,
    summary: .security_advisory.summary,
    ghsa: .security_advisory.ghsa_id,
    package: .security_vulnerability.package.name,
    ecosystem: .security_vulnerability.package.ecosystem,
    vulnerable: .security_vulnerability.vulnerable_version_range,
    first_patched: .security_vulnerability.first_patched_version.identifier,
    manifest: .dependency.manifest_path,
    relationship: .dependency.relationship,
    scope: .dependency.scope,
    url: .html_url
  }'

If gh returns 403/404, report missing security_events or dependabot_alerts permission and stop.

Step 3: Keep only actionable fixes

Include an alert only when all of the following hold:

• Severity is in the active filter (Step 1 table).
• first_patched is not null (Dependabot reports a patched version).
• State is open.

Collect alerts without a patch (first_patched == null) into a separate „No automated fix“ list in the plan — no todo for those.

Step 4: Group and deduplicate

Multiple alerts can refer to the same dependency in the same manifest. One todo per group, not per alert number.

Group key: (manifest, ecosystem, package).

Per group, retain:

• All alert numbers and URLs
• Highest required first_patched version (prefer semver comparison; if incomparable, list each distinct target and split into separate todos)
• Worst severity in the group
• Combined summaries (short)

Step 5: Investigate fix path per group

Before writing todos, determine how the fix would be applied. Check in the target repo (clone, existing workspace, or gh):

Also check for existing work:

gh pr list -R {owner}/{repo} --author "app/dependabot" --state open --json number,title,url

If an open Dependabot PR already addresses a group, reference it in that todo instead of planning manual work.

Skip groups where the installed version (from lockfile/manifest in repo) is already >= first_patched — mark as likely stale alert in the plan summary, not as a todo.

Step 6: Build Plan with one todo per fix

Use Plan mode (SwitchMode → plan) when available. Otherwise present the same structure in chat.

Plan title: Dependabot security fixes — {owner}/{repo}

Plan body template:

# Dependabot security fixes — {owner}/{repo}

Source: https://github.com/{owner}/{repo}/security/dependabot
Severity filter: {critical, high [, medium]}
Fetched: {date}
Actionable fixes: {N} | No patch available: {M} | Stale/skipped: {K}

## Summary

{1–3 sentences: dominant packages, ecosystems, risk overview}

## Fixes

{For each group — this section mirrors todos 1:1}

### {N}. {package} ({ecosystem}) → {target_version}

- **Severity:** {critical|high|medium}
- **Manifest:** `{manifest}` ({relationship}, {scope})
- **Alerts:** [#{num}]({url}), …
- **Advisory:** {short summary}
- **Proposed fix:** {concrete command or file change}
- **Verify:** {test / build / audit command}

## No automated fix

| Package | Severity | Alerts | Notes |
|---------|----------|--------|-------|
| … | … | … | No `first_patched_version` from Dependabot |

## Suggested order

1. Critical first, then High, then Medium
2. Direct dependencies before transitive
3. Shared base manifests before leaf packages

Todos: Create exactly one todo per group in Step 4 (after dedup). Todo text format:

Fix {package} ({ecosystem}) in {manifest}: upgrade to >={target_version} — {severity} — alerts #{numbers}

Use TodoWrite to register the same items when not in Plan mode.

Rules

• Repository-agnostic — resolve {owner}/{repo} at runtime; never hardcode or assume a specific repository.
• Plan only — no version bumps, commits, or PRs unless the user confirms after the plan.
• Actionable only — todos require a known patched version from Dependabot.
• One fix, one todo — dedupe duplicate alerts; split only when the same package needs incompatible target versions.
• German or English — match the user’s language in the plan text; keep todo IDs/slugs ASCII.
• If zero actionable fixes remain after filtering, say so clearly and still list „No automated fix“ and stale alerts if any.

Example invocations

→ Fetch alerts for the resolved repo → filter → group → plan with todos.