/patch-sweep

name: patch-sweep
description: "Respond to a CVE wave across a whole portfolio of apps at once: inventory every repo and the platform project and domain it actually serves, find the real production branch, spot stale manual deploys, decide which apps are affected, mitigate, patch, ship, and confirm production. Use when the user mentions 'patch sweep,' 'patch all my apps,' 'fleet-wide CVE,' 'are any of my apps affected,' 'Next.js RCE across all projects,' 'Rails CVE on all our Heroku apps,' 'patch every repo,' 'CVE wave,' 'security release across the fleet,' 'which of our sites run the vulnerable version,' 'mass dependency update,' or has more than a handful of apps to patch against the same advisories."
allowed-tools: Read, Grep, Glob, Bash(gh repo list:*), Bash(gh repo view:*), Bash(git log:*), Bash(git ls-remote:*), Bash(vercel project ls:*), Bash(vercel project inspect:*), Bash(vercel ls:*), Bash(vercel inspect:*), Bash(vercel domains ls:*), Bash(heroku apps --all --json), Bash(heroku apps:info:*), Bash(heroku domains -a:*), Bash(heroku releases -a:*), Bash(heroku releases:info:*), Bash(heroku pipelines:info:*)

Patch Sweep — Fleet-Wide CVE Response

`dependency-audit` patches one project. This skill runs the response when a batch of advisories lands and you have 10, 40, or 100 apps across Vercel, Heroku, Render, Netlify, Fly, or Railway, split between a personal account, an agency org, and client repos.

Most of the real work in a sweep is outside `npm audit`: knowing which repo serves which domain, which branch production actually builds from, which production deploys no merge will ever replace, and which apps aren't affected at all. Get the map right first. Patching the wrong branch of the wrong repo is the most common way a sweep "finishes" with vulnerable code still live.

Cross-references:

• `dependency-audit` — the per-project audit and fix procedure (in-range fixes, pnpm/yarn traps, duplicate singletons, engines floor, runtime pins). This skill calls it once per affected app.
• `cloud-audit` "PaaS" section — platform posture: stale manual deploys, broken git deploys, legacy projects, preview exposure, repo security defaults.
• `scanner-pipeline` — run osv-scanner / trivy once per repo instead of separate per-package-manager audits, and keep it running weekly afterward.
• `finding-triage` — rank the leftovers that can't be patched in range.
• `security-comms` — client and stakeholder notices, especially for client repos you can only PR.
• `vuln-research` — when an advisory's affected range or code path is unclear.

Authorization — confirm before touching anything

Ask the user, and write the answers at the top of the board:

1. **Which accounts are in scope?** List each GitHub owner/org and each platform team/account. Only repos and platform accounts the user controls are in scope for merges and deploys. 2. **Which repos belong to someone else?** Client repos, repos owned by another maintainer, and anything where the user is a collaborator rather than the owner. These get a **PR assigned to the owner, never a push or merge**, even if the user's token has write access. 3. **Who can approve an owner decision?** Stale manual deploys, legacy projects, and duplicate projects need someone to decide. Name that person per account. 4. **Is a production deploy allowed today?** Some clients have change windows or freeze periods.

Refuse to: push to or merge into a repo the user doesn't own without that owner's explicit approval in the user's own message; deploy to a platform account the user doesn't control; delete projects, domains, or deployments as part of the sweep (that's an owner decision, recorded as an action); disable deployment protection, branch protection, or CI checks to make a patch land faster.

The listed `allowed-tools` are read-only inventory commands, scoped so no grant prefix-matches a write (`heroku releases -a:*`, never `heroku releases:*`, which would also match `releases:rollback`). Every merge, `vercel deploy`, `git push`, `heroku config:set`, and `gh api -X PUT` prompts on purpose.

Step 1 — Inventory and mapping

Build one row per **deployed app**, not per repo. A repo can feed several projects; a project can outlive its repo.

**Repos** (per owner/org; skip forks and archived repos):

gh repo list <owner> --limit 1000 --source --no-archived \
  --json nameWithOwner,defaultBranchRef,isPrivate,pushedAt,viewerPermission

`viewerPermission` tells you whether you're `ADMIN`, `WRITE`, or below. It does not tell you whether the repo is yours to merge into; ownership comes from the authorization step.

**Vercel** (per team; repeat with `--scope <team>`):

vercel project ls --format json --scope <team>
vercel project inspect <project> --scope <team>
vercel domains ls --scope <team>
vercel api /v9/projects/<project> --scope <team>           # link.org/repo, link.productionBranch, commandForIgnoringBuildStep
vercel api /v9/projects/<project>/domains --scope <team>   # every domain attached to the project, incl. *.vercel.app

**Heroku:**

heroku apps --all --json          # includes team apps
heroku domains -a <app>
heroku apps:info -a <app> --json  # stack, region, git url

Heroku doesn't record a "source repo" unless the GitHub integration or a pipeline is set up; check `heroku pipelines:info <pipeline>` or the dashboard's Deploy tab, and ask when it isn't there.

**Render** (API; token from the dashboard):

curl -s -H "Authorization: Bearer $RENDER_API_KEY" "https://api.render.com/v1/services?limit=100"
# per service: repo, branch, autoDeployTrigger, serviceDetails.runtime
curl -s -H "Authorization: Bearer $RENDER_API_KEY" "https://api.render.com/v1/services/<id>/custom-domains"

**Netlify / Fly / Railway:** `netlify sites:list --json`, `fly apps list` + `fly certs list -a <app>`, `railway list` / the dashboard. Same columns.

Flag these as you go; each is a row in the board with an owner action:

| Flag | How to