用途
该技能用于处理 Paperclip 项目通过 GitHub Security Advisory 报告的安全漏洞，覆盖从公告分诊、私有 fork 修复、CVE 申请到公告与补丁同步发布的完整响应流程。核心目标是在漏洞公开与修复可用之间实现零窗口，避免攻击者在用户升级前利用漏洞。
保密要求
整个流程在公告发布前均为机密。禁止在公开提交信息、PR 标题、分支名或评论中提及漏洞细节；禁止推送到公开分支；禁止在公开渠道讨论具体内容。假设公开仓库上的一切内容对攻击者可见。
主要能力与步骤
Step 0：获取公告详情
使用 gh api repos/paperclipai/paperclip/security-advisories/{{ghsaId}} 拉取完整公告，阅读 description、severity、cvss 和 vulnerabilities 字段，在编写代码前理解攻击向量。
Step 1：确认报告（需人工） 公告线程没有评论 API，需请人工操作者在私有公告线程中发布确认评论，技能提供模板。
Step 2：创建临时私有 fork
使用 gh api --method POST repos/paperclipai/paperclip/security-advisories/{{ghsaId}}/forks 创建私有 fork，保存 full_name 和 clone_url，克隆到 ~/security-patch-{{ghsaId}} 并创建通用分支名（如 security-fix）。不要编辑 ~/paperclip，不要提交 pnpm-lock.yaml，不要使用泄露漏洞的描述性分支名。CI/GitHub Actions 不会在临时私有 fork 上运行，需本地运行测试。
Step 3：开发并验证修复 编写补丁，要求功能可用、考虑整个代码库而非仅漏洞路径、保证数据库向后兼容、UI 组件显示正确、修复最小且聚焦。安全修复需先复现漏洞再确认补丁阻止攻击，考虑相邻攻击向量，避免引入新依赖。推送至私有 fork。
Step 4：与报告者协调（需人工） 请人工操作者在公告线程发布修复就绪通知，技能提供模板。
Step 5：申请 CVE
使用 gh api --method POST repos/paperclipai/paperclip/security-advisories/{{ghsaId}}/cve 申请 CVE，使漏洞扫描器（npm audit、Snyk、Dependabot）能提醒用户升级。GitHub 作为 CVE 编号机构会自动分配，CVE 在公告发布后可能需数小时传播。
Step 6：同步发布
所有步骤同时进行，不得错开。6a 验证报告者署名，如未署名则通过 PATCH 添加 credits；6b 更新公告的 patched version 并发布（state 设为 published），发布公告会同时公开 GHSA、合并临时私有 fork 并触发 CVE 分配；6c 合并后立即发布版本，使用 gh release create 创建安全版本，包含修复说明、公告链接、致谢和升级要求。
Step 7：发布后验证 验证公告已发布且 CVE 已分配，验证版本存在。CVE 尚未分配属正常，可能需数小时。需请人工操作者在公告线程发布最终确认评论并致谢报告者。最后向任务发布评论，说明已发布的公告 URL、版本 URL、CVE 是否已分配以及所有 PR 或分支 URL。
适用场景
适用于 Paperclip 项目收到 GitHub Security Advisory 报告后的机密响应协调，包括分诊、私有修复、CVE 申请和同步发布。
限制
部分步骤（确认报告、协调报告者、发布后致谢）需要人工操作者执行，因为公告线程没有评论 API。CI 不会在临时私有 fork 上运行，必须本地测试。CVE 分配和传播可能需要数小时。