mcpField
U
use-my-browser

use-my-browser

github.com/xixu-meAgent 工作流79505.7k 次安装3 天前更新
代码仓库

关于 use-my-browser

use-my-browser 是一项指导 Agent 根据证据需求选择浏览器或静态检索路径的技能，面向需要处理网页信息或交互任务的场景。它强调先确认实时浏览器能力，并按任务类型加载相应流程与参考资料。

主要功能

  1. 01区分静态检索与浏览器必需任务
  2. 02检查实时浏览器能力
  3. 03按任务加载专用参考资料
  4. 04记录并维护网站操作模式

适用场景

  1. 01判断任务是否必须依赖页面可见状态
  2. 02在登录页面中执行保存或发布操作
  3. 03排查 iframe、Shadow DOM 或反自动化问题

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/xixu-me/skills --skill use-my-browser

安装后在 Claude Code 中输入/use-my-browser确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

README.md
README.zh.md
references/
anti-automation-friction.md
browser-capability-matrix.md
browser-playbook.md
browser-recovery.md
control-plane-workflows.md
debug-handoff.md
deep-dom.md
media-inspection.md
parallel-browser-ownership.md
selector-bridge.md
task-routing.md
references/site-patterns/
README.md

详细介绍

不要将此技能当作通用的浏览默认方案。应根据所需证据选择路径，而非根据对工具的偏好选择。

选择路径之前，必须先对每项任务进行分类：

  • static-capable：无需实时浏览器状态、可见确认或页面交互即可获取证据
  • browser-required：证据取决于渲染状态、交互、实时会话行为或仅限浏览器的结构

只有 static-capable 任务可以改用静态检索、curl 或其他非浏览器路径。一旦任务属于 browser-required，就必须坚持使用浏览器路径；如果缺少所需能力，应标记为 blocked，而不是悄悄降级。

前置条件检查

此技能用于在用户当前的实时浏览器会话中执行操作，而非启动一个全新的独立自动化浏览器。

在进行浏览器自动化之前，请确认当前环境已经能够访问实时浏览器技术栈，并能提供任务所需的能力，例如页面清单、创建任务专用页面、页面选择、快照或可见状态读取、DOM 检查、文本或表单输入、上传、对话框、控制台检查和网络检查。具体使用哪种技术栈并不重要：确认能力即可，无需确认品牌。

如果无法访问实时浏览器技术栈，请勿通过此技能尝试进行浏览器自动化。只有 static-capable 任务可以改用静态检索。

实时浏览器自动化可能会触发某些网站的反机器人或反自动化防护。仅在任务确实需要时才进行浏览器交互；获取所需证据后，避免不必要的重复操作。

经验循环

将网站模式视为浏览器协议的一部分，而非可有可无的背景资料。

对于 browser-required 任务，请按以下流程操作：

  1. 确定目标域名后，立即检查 references/site-patterns/ 下是否已有相应说明。
  2. 如果有说明，请在首次对该域名执行实质性浏览器操作之前阅读。
  3. 执行任务期间，留意是否发现会影响未来操作方式、且经过验证的网站特定事实。
  4. 在认为任务完成之前，判断本次运行是否获得了可复用的经验、证伪了已有经验，或未发现可复用的网站特定经验。
  5. 如果本次运行验证了可复用信息或证伪了已有说法，请在结束前更新相应说明。

不要因一次性杂项信息而创建域名说明。即使任务本身已成功，也不要跳过运行结束时的复查。

如果本次运行验证了以下任一事项，预期应将其写回：

  • 稳定的路由形式或必需的查询参数
  • 登录、会话继承或 isolatedContext 特性
  • 可靠的交互方式，例如悬停、键盘输入、上传顺序或选择器桥接模式
  • DOM 生成的链接可靠，但手动构造的 URL 不可靠的域名
  • 可预测的反自动化阻碍或误导性的平台错误状态
  • 可复用的媒体提取方式，或 iframe / Shadow DOM 访问模式

决策指南

从结果出发，而不是从工具出发。明确用户的目标，定义怎样才算完成，并选择能够提供正确证据的最低成本方案。

按以下顺序选择路径：

  1. 判断任务属于 static-capable 还是 browser-required。
  2. 如果任务属于 static-capable，加载 references/task-routing.md，并选择仍能满足证据目标的最低成本方案。
  3. 如果任务属于 browser-required，加载 references/browser-playbook.md。
  4. 如果在新的宿主会话中无法确定是否具备浏览器所需能力，还要加载 references/browser-capability-matrix.md。
  5. 如果用户已经有正在进行的浏览器调试上下文，例如选中的检查器元素或网络请求，还要加载 references/debug-handoff.md。
  6. 如果浏览器所需任务涉及已登录的仪表板、管理界面、CMS、编辑器或任何保存／发布／更新流程，还要加载 references/control-plane-workflows.md。
  7. 如果当前故障形态表明可能存在软 404、内容不可用状态、可疑的无效交互、身份验证拦截、速率限制或反自动化防御，还要加载 references/anti-automation-friction.md。
  8. 如果浏览器所需任务包含 iframe、Shadow DOM、折叠内容或延迟加载的证据，还要加载 references/deep-dom.md。
  9. 如果重要证据位于图像、音频片段或视频中，还要加载 references/media-inspection.md。
  10. 如果可以由不同页面负责人或子 Agent 并行处理浏览器工作，还要加载 references/parallel-browser-ownership.md。
  11. 如果已知可靠的选择器，但需要 MCP 原生的 uid 目标，还要加载 references/selector-bridge.md。
  12. 如果页面操作后的状态不明确、页面意外跳转、旧 uid 可能已失效，或现在需要检查控制台／网络以解释下一步浏览器决策，还要加载 references/browser-recovery.md。
  13. 如果目标网站已在 references/site-patterns/ 下有对应的域名说明，请在操作网站前阅读该说明。

默认将以下情况视为 browser-required：

  • localhost、127.0.0.1 或基准测试风格的本地夹具
  • 上传、下载、拖放、悬停、原生键盘输入或可见的确认状态
  • 同源 iframe 检查、Shadow DOM 检查、details／折叠证据或延迟加载内容
  • 任何将“页面上可见的内容”本身作为证据的任务

常见任务的常规顺利路径是使用此入口和一两份参考文档，而不是整个参考文档集。

硬性规则

  • 只有当实时浏览器状态是证据的一部分或执行操作所必需时，才使用浏览器交互。
  • 任务一旦被判定为 browser-required，就不得悄悄降级。
  • 将此文件视为入口点，将每个参考文件视为单一用途的权威来源。不要在多个文件中重复规则。
  • 参考文件只加载一层。根据此入口点决定要读取的下一个文件，不要将某个参考文件变成链接到更多参考文件的枢纽。
  • 不要仅因页面看起来受限就要求用户登录。先确认目标内容或操作是否确实受阻。
  • 页面显示预期路径后，优先使用网站生成的 DOM 链接，而不是手动拼接 URL。
  • 如果任务确实需要在浏览器中执行操作，优先使用 MCP 原生操作，而非脚本驱动的交互。
  • 只关闭由你创建的页面。
  • 优先使用一手来源，而非聚合网站或重复的二手报道。
  • 如果存在匹配的网站模式说明，在该域名上首次执行有实质影响的浏览器操作前，先阅读该说明。
  • 完成 browser-required 任务前，必须明确检查此次运行是否应创建、更新、降级或删除网站模式声明。
  • 如果现有网站模式声明在可比条件下失效，就停止信任该声明，改用通用工作流，并更新说明，而不是继续依赖过时的假设。
  • 对于 browser-required 任务，不得使用 curl、Invoke-WebRequest 或 Shell HTTP 抓取。
  • 不要将通用页面打开工具视为 localhost 深度交互可用的证据。
  • 不要仅因浏览器能力探测失败就切换路线。记录缺失的能力，然后停止。
  • 用户表示当前有正在进行的浏览器调试上下文时，优先从该上下文接手，而不是从头重新复现。

参考索引

评论

支持 Markdown