用途 Patch Sweep 用于在一批安全公告集中出现时，对多个应用做统一响应。它面向的场景是 10、40 甚至 100 个应用分散在 Vercel、Heroku、Render、Netlify、Fly、Railway 等平台，且分属个人账号、机构组织和客户仓库。它指出批量响应的真正难点不在 npm audit 本身，而在于弄清哪个仓库服务哪个域名、生产实际从哪个分支构建、哪些生产部署永远无法被合并替代、哪些应用其实不受影响。
主要能力
- 授权确认：先向用户确认纳入范围的 GitHub 所有者/组织与平台账号，区分他人所有的仓库（客户仓库、其他维护者仓库），并明确谁能批准所有者决策、当前是否允许生产部署。
- 清单与映射：按已部署应用而非仓库建立行，使用 gh repo list、vercel project ls/inspect/api、heroku apps/domains/apps:info、Render 服务 API 等只读命令，记录仓库、平台项目、域名、生产分支、根目录等信息。
- 风险标记：识别仍对外提供服务的遗留项目、无自定义域名的项目、同一仓库的重复项目、没有对应平台项目的仓库，并为每项记录所有者行动。
- 生产分支确认：不假定默认分支，从平台读取实际生产分支，并比较生产部署提交与分支 HEAD。
- 陈旧与手动部署检测：识别来自 CLI 的手动生产部署、持续失败的 git 部署、生产提交不在生产分支上的情况。
- 影响判断：要求运行时/依赖版本、受影响组件存在、受漏洞代码路径被使用三者同时成立，并记录排除原因；区分停止维护的版本线、平台托管运行时的自动修补、以及未被使用的代码路径。
- 先缓解后修补：优先应用环境变量开关、WAF/防火墙规则、关闭易受攻击功能、部署保护等补偿控制。
- 逐应用修补：从生产分支创建热修复分支，只做范围内修复，同步移动所有运行时版本固定点，本地或 CI 运行 lint、类型检查与构建，验证预览部署与关键路由，合并到生产分支，确认生产部署与自定义域名可用，再回同步到集成分支。
- 委派与并行：每个代理约 6 个仓库，注意构建队列并发限制，他人仓库只开 PR 并指派审查。
- 预防措施：开启 Dependabot 告警与秘密扫描，安排每周扫描，处理陈旧手动部署与遗留项目，并在 README 记录生产分支。
使用方式 技能通过只读清单命令收集信息，所有合并、部署、推送、配置修改与 gh api 写操作都会先提示确认。用户需提供纳入范围的账号、他人仓库清单、决策批准人、变更窗口等信息。最终输出为状态看板，按仓库列出平台项目、域名、生产分支、运行时或框架版本变化、严重/高危数量前后对比、是否合并、生产是否返回 200、剩余需大版本升级项与所有者行动。
适用场景 适用于跨多个平台和应用组合的集中 CVE 响应、客户仓库的补丁 PR 交付、遗留与手动部署治理、以及补丁后的预防性安全配置。
限制 技能拒绝向非本人所有仓库推送或合并、拒绝部署到不受控平台账号、拒绝在批量响应中删除项目/域名/部署、拒绝为加速补丁而关闭部署保护、分支保护或 CI 检查。手动部署、遗留项目和重复项目的取舍属于所有者决策，技能只记录行动选项。大版本升级、未知影响项需单独处理。具体收费、价格与更多平台支持细节资料暂未提供。