技能介绍

要解决什么问题

很多智能体任务并不是「拉一段 HTML」就能做完的：登录态、localStorage、客户端渲染、扩展注入、以及用户眼前真实打开的标签页，都会改变页面长什么样、按钮能不能点。静态 HTTP 或离线文件读不到这些运行时状态，也容易把「请求成功」误当成「页面已经按业务规则更新」。

Omnibot 的定位是面向 AI Agent 的浏览器基础设施：通过本机 omnibot daemon 与 CLI，把 Hermes、Claude Code、Codex、OpenCode 等执行端接到真实的 Chromium，让智能体在需要证据链的场景里读渲染结果、点控件、填表、导航并做校验。

技能如何约束执行

这份 SKILL 是给智能体看的执行规范，不是给人手敲命令的说明书。核心思路可以概括为：

可靠性优先：Observe → Act → Verify，没有校验证据就不宣称成功。
显式状态：工作流用 OMNIBOT_SESSION_TOKEN 隔离上下文；凡触及页面状态的命令都要带 --tab-id，不依赖「当前标签页」的隐式假设。
原生命令优先：先走 snapshot -i、find … --action click、fill/type、wait 等子命令；execute-js 只在原生路径证明够不着时再作为退路。
分步与防重复：多步任务按「观测 → 单步变更 → 验证」拆开；终端超时或空输出时，下一步先做只读探测，避免重复 fill/click 改坏业务状态。

命令路由上也有明确分工：页面身份用 get title/get url；内容与控件用 read、get text、snapshot；跨域 iframe、剪贴板、原生对话框等边界在规范里单独写了验证方式。

适用边界与注意点

适合：必须依赖浏览器运行时、可见 UI、Cookie/存储、扩展或网络抓证的任务。
不适合：纯静态文件或普通 HTTP 已能回答的问题——不必强行开浏览器。
高风险流程：购物结账、支付、银行等不可逆操作，规范要求未经用户在本轮明确确认，不得点击最终提交/支付控件。
源码联调：若工作区是 Omnibot 源码检出，需用工作区内的 daemon/CLI（如 uv run），避免全局安装的 daemon 悄悄测到另一套代码。

截图预览

使用场景

智能体要在已登录的 SaaS 控制台里点侧栏、改一项配置，并用 `get`/`is` 核对页面上出现的保存成功提示，而不是只读未登录的静态接口。
需要在对某个按钮执行一次点击前后，用 `network clear → start → stop → logs` 抓取请求摘要，作为「前端是否真的发了这笔调用」的取证材料。
单页应用表单带客户端校验：用 `fill` 或 `type` 写入字段，先验证控件 `value`，再视情况点 Save/Apply，避免把 DOM 改了却未触发业务提交。
长流程拆成多轮：每轮固定 `OMNIBOT_SESSION_TOKEN` 与 `--tab-id`，`snapshot -i` 后再点 `@eN`，失败则重新观测而不是复用过期 ref。