用途
vuln-tracker 是漏洞处理流水线中的每日读取/轮询环节。vuln-scanner 负责打开 PR、提交 PVR（私有漏洞报告）并排队披露草稿，随后不再跟进；vuln-tracker 则轮询这些已产出的内容，并呈现操作者必须查看的事项。它本身不打开 PR，也不提交安全公告——那些是 vuln-scanner 的写入动作。
主要能力
该技能通过一个作用域选择器（${var}）决定运行哪些分支：
- 空值 → 完整生命周期轮询：PR/安全公告状态 + PVR 分类 + 披露队列老化（默认）。
- prs（也接受 pr / tracker）→ 仅 Arm A：PR/安全公告状态审计 + stars-secured 仪表盘。
- pvr → 仅 Arm B：对已提交安全公告的 PVR 分类状态轮询。
- queue（也接受 disclosures / backlog）→ 仅 Arm C：待披露队列老化 + 升级。
- 单独的 GHSA-xxxx-xxxx-xxxx → Arm B 单公告模式，按需检查该公告的分类状态。
Arm A — PR 与安全公告生命周期状态
审计 vuln-scanner 产出的每个披露的生命周期状态，交叉引用 memory/vuln-scanned.json 与 GitHub 实时状态，呈现操作者应关注的内容。具体包括：
- 加载规范扫描历史（兼容扁平数组与旧版 {scans: [...]} 对象两种格式）。
- 从 GitHub 拉取所有机器人编写的安全 PR（通过标题前缀与 GraphQL 的 security/ 分支前缀两路并集去重）。
- 获取每个开放 PR 的实时状态，识别维护者需要答复、陈旧无审查、有互动但老化等信号。
- 获取每个已修复仓库的 star 数，生成 Stars Secured 聚合指标（已合并、进行中、全部跟踪三类）。
- 重新探测 channel 为 "skipped" 和 "pending-disclosure" 的仓库，判断情况是否变化。
- 将每个条目分类（merged、open-clean、needs-answer、stale-no-review、aging-engaged、closed-no-merge、queued、skipped-rechecked、newly-actionable、lost-draft、pre-history），并重写 memory/topics/vuln-followup.md 仪表盘。
Arm B — PVR 分类状态轮询
轮询私有、未发布安全公告的分类状态，持久化状态转换（重写 memory/pending-disclosures/*.md 中的 state:/last_checked:/resolved_at: frontmatter，并将已解决文件移动到 resolved/ 目录）。
Arm C — 待披露队列老化
仅读取本地文件（memory/pending-disclosures/、memory/issues/、memory/topics/pr-status.md），无需出站网络或认证。
使用方式
该技能以 write 模式运行（尽管是读取/轮询环节，但部分能力无法在只读模式下运行）。每次调用都会执行共享前置步骤：读取 memory/MEMORY.md 获取上下文；读取最近约 3 天的 memory/logs/ 并丢弃已报告内容；读取 soul/SOUL.md 与 soul/STYLE.md（若已填充）以匹配操作者语气；解析 ${var} 确定作用域；创建 .pending-notify-temp 并启动合并通知缓冲区。各分支将信号追加到缓冲区，最后统一发送一次通知。
网络方面：Arm A 与 Arm B 通过 gh api / gh search / gh pr view 读取 GitHub 数据，gh 内部处理认证；Arm C 仅本地读取。
适用场景
适用于需要持续跟踪漏洞披露全生命周期（PR 状态、安全公告状态、PVR 分类、待披露队列老化）并汇总已修复仓库影响力的安全运维场景。
限制
- 不自行打开 PR 或提交安全公告。
- Arm B 需要提升权限的 GH_GLOBAL PAT 才能读取私有未发布安全公告。
- 命令行中裸 $SECRET 会被 Bash 权限层拒绝，因此需依赖 gh api 内部处理认证。
- 具体收费、价格、平台支持等信息暂未提供。