关于 competition-browser-persistence
用于调查影响应用行为的浏览器持久状态，而非仅依赖可见 HTML 或后端代码的 CTF 技能，须在 `$ctf-sandbox-orchestrator` 建立沙箱假设与证据优先级后使用。
主要功能
- 01梳理浏览器存储面
- 02记录来源与作用域边界
- 03关联存储状态与运行效果
- 04比较干净状态和修改状态
- 05简化为最小因果链
适用场景
- 01追踪 Cookie 如何进入请求头
- 02检查存储状态驱动的路由可见性
- 03比较缓存与实时 API 行为
- 04复现有状态的浏览器分支
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/competition-browser-persistence确认已加载。
附带文件agents/openai.yamlreferences/browser-persistence.md
详细介绍
竞赛浏览器持久化
仅当 $ctf-sandbox-orchestrator 已经激活，并且已经建立沙箱假设、节点归属和证据优先级之后，才将此技能作为下游专项技能使用。如果尚未做到这一点，请先回到 $ctf-sandbox-orchestrator。
当决定性分支存在于浏览器持有的状态中，而不只是存在于可见 HTML 或后端源码中时，请使用此技能。
除非用户明确要求英文，否则请用简体中文回复。
快速开始
- 首先识别当前活跃的持久化面：cookie jar、localStorage、sessionStorage、IndexedDB、Cache Storage 或 service worker。
- 在修改状态之前，记录 origin、scope、domain、path、expiry 和 key 名称。
- 将存储状态与一个具体效果关联起来：请求头、渲染分支、缓存响应、离线行为或隐藏路由访问。
- 将启动时状态与运行时被修改的状态区分开。
- 复现能够到达决定性分支的最小有状态序列。
工作流
1. 梳理浏览器状态面
- 检查 cookies、storage buckets、service worker 注册、cache entries，以及启动期间暴露的临时全局变量。
- 记录每个状态项实际适用于哪个 origin、host、route 或 feature flag。
- 将 auth tokens、refresh material、CSRF state、缓存响应和 feature toggles 保存在彼此独立的证据块中。
2. 将状态与运行时行为关联起来
- 展示存储状态如何变成请求头、角色推导、路由可见性、缓存 API 数据或离线回退行为。
- 比较干净状态与修改后状态的运行结果，每次只改变一个变量。
- 区分仅 UI 状态与后端接受的状态。
3. 约简到决定性持久化链
- 将结果压缩为最小链条：初始页面或登录 -> 状态被持久化 -> 后续请求或渲染分支 -> 最终能力。
- 让提取出的 storage、service worker 脚本和重放步骤保持绑定到同一 origin 和 route。
- 如果问题扩展到浏览器持久化之外的一般 Web 路由或 worker 行为，请切回更广泛的 Web 运行时技能。
阅读此参考
- 加载
references/browser-persistence.md，获取浏览器状态检查清单、service-worker 检查清单和证据打包方式。
需要保留的内容
- Cookie 属性、storage keys、数据库名称、cache keys、service worker scopes 和 origin 边界
- 每个决定性状态项所造成的精确请求或渲染效果
- 最小可用路径的干净状态与修改后状态复现步骤
评论
支持 Markdown