القائمة
Use when working with the built-in desktop Workbench Browser, browser comments, browser snapshots, CDP actions, screenshots, or the browser versus agent-browser boundary.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when deciding between follow-up queues, scheduled callbacks, automation-owned attention, wakeups, and async follow-up surfaces.
Use when a task benefits from JavaScript orchestration, explicit phases, structured progress logs, parallel fanout, or multiple daemon-backed subagents coordinated through the workflow tool.
Use when starting, inspecting, rerunning, following up, or cancelling durable background commands or subagents.
Use when designing, creating, editing, building, validating, installing, or debugging Neon Pilot extensions, application pages, contributions to existing applications, or complete first-class applications from the bundled desktop app. This skill is self-contained and must be used without a Neon Pilot source checkout.
Use the unified Neon Pilot CLI/control plane for self-administration, delegated agent control, conversations, workspace/sidebar state, runs, automations, extensions, settings, and extension-contributed administration surfaces.
Use when installing, inspecting, or explaining Codex and Claude Code style agent plugins in Neon Pilot.
| name | browser |
| description | Use when working with the built-in desktop Workbench Browser, browser comments, browser snapshots, CDP actions, screenshots, or the browser versus agent-browser boundary. |
| metadata | {"id":"browser","title":"Built-in Workbench Browser","summary":"Guidance for the desktop workbench Browser tab, browser comments, and how it differs from the agent-browser CLI.","status":"active"} |
The built-in Browser is the user-facing browser surface inside the Electron desktop app's Workbench layout.
Use this extension skill when work touches:
agent-browser CLI/dev toolThe Workbench Browser is an Electron-owned WebContentsView embedded in the desktop app.
It is for:
It is not a general-purpose replacement for Chrome, and it should not expose agent/debug controls directly to normal users.
This distinction matters in prompts: the built-in browser tools are a communication tool. Use them when the user is showing the agent a page, asking about the visible Workbench Browser, or wants the agent to act on the same page they can see. Do not treat them as the default development automation harness.
The Browser tab should stay boring:
Do not show agent-only controls such as JSON action batches, raw snapshots, or automation debug output in the user UI. If those capabilities exist, keep them behind agent/tool APIs or developer diagnostics.
Right-clicking inside the browser and choosing Comment on this captures a target bundle and opens a small comment box over the page.
The target bundle should include enough metadata for both humans and agents:
When the comment is saved, it appears as a pending composer marker. On prompt send, pending browser comments are injected as contextMessages with customType: "browser-comments", then cleared after successful send. If send fails, pending comments should be restored with the rest of the composer draft.
Browser comments are prompt context, not durable page annotations. Avoid building a full annotation database until there is a clear need.
There is one browser session per conversation workbench and three agent-facing browser tools:
browser_snapshot — observe the current browser statebrowser_cdp — send one or more Chrome DevTools Protocol commands to the current browser sessionbrowser_screenshot — capture the current browser viewport as an imageThese tools should target the built-in Workbench Browser session, not an unrelated Playwright/agent-browser session.
Use these tools for shared conversation context. If the task is autonomous development validation, black-box UI testing, local app smoke checks, repeatable browser automation, or screenshots of the product under test, use the agent-browser skill/CLI through shell instead.
The product model:
Avoid creating two unrelated browsers for the same task. A Playwright/agent-browser session and the built-in Electron Browser tab drifting apart is bad UX.
browser_snapshotUse browser_snapshot as the browser equivalent of read: it gives the agent eyes.
It should return:
@e1, @e2, etc.Example shape:
URL: https://example.com/login
Title: Sign in
@e1 role=textbox name="Email" selector="input[name=email]" enabled=true
@e2 role=textbox name="Password" selector="input[name=password]" enabled=true
@e3 role=button name="Sign in" selector="button[type=submit]" enabled=true
Refs are snapshot-scoped. After navigation or major DOM changes, take a fresh snapshot before using refs again.
Prefer accessibility data for role/name/state, but always include DOM fallback selectors so the page can be inspected and discussed clearly.
If the user manually changes the page after the last agent snapshot — for example logging in, clicking, typing, or navigating — the next user prompt includes browser-changed-since-snapshot context. Treat that as a stale-observation warning and call browser_snapshot before assuming the old page state is still true.
browser_cdpUse browser_cdp when direct browser control is needed. It sends raw Chrome DevTools Protocol command objects to the current Workbench Browser session. Send a single object for one command:
{
"command": {
"method": "Runtime.evaluate",
"params": { "expression": "document.title", "returnByValue": true }
}
}
Send an array of command objects for multi-step actions instead of firing many separate tool calls:
{
"command": [
{
"method": "Input.dispatchMouseEvent",
"params": { "type": "mouseMoved", "x": 300, "y": 250 }
},
{
"method": "Input.dispatchMouseEvent",
"params": {
"type": "mousePressed",
"x": 300,
"y": 250,
"button": "left",
"clickCount": 1
}
},
{
"method": "Input.dispatchMouseEvent",
"params": {
"type": "mouseMoved",
"x": 520,
"y": 420,
"button": "left",
"buttons": 1
}
},
{
"method": "Input.dispatchMouseEvent",
"params": {
"type": "mouseReleased",
"x": 520,
"y": 420,
"button": "left",
"clickCount": 1
}
}
]
}
The tool is intentionally thin. Agents should provide CDP method names and params exactly as Chrome expects. Commands execute sequentially and stop on the first protocol error unless continueOnError is true. Useful commands include:
Runtime.evaluate for page JavaScript and structured page inspectionPage.navigate for navigationDOM.getDocument, DOM.querySelector, and related DOM commands for node-level inspectionInput.dispatchMouseEvent and Input.dispatchKeyEvent for low-level inputPrefer browser_snapshot for normal observation and browser_screenshot for visual checks. Use CDP when the task needs direct control or a specific protocol capability.
browser_screenshotUse browser_screenshot when visual layout matters or when DOM/accessibility snapshots are not enough.
Default to browser_snapshot. Snapshot is preferred for normal browsing because it is structured, cheaper, includes refs/selectors, and is better for text, feeds, lists, forms, buttons, and current page state. Do not use screenshots just to read a page.
Good screenshot cases:
browser_snapshot is missing information needed to answer correctlyIt should return an image attachment or image data plus basic metadata:
Current desktop tool output returns PNG data as base64 in tool details with URL/title/viewport metadata.
When any built-in browser tool runs from a desktop conversation:
Do not show raw script/debug panels in the user Browser tab. The transcript is where tool details belong.
agent-browseragent-browser is still useful as a CLI/dev validation tool. In this repo, use it through npm run ab:run as documented in Agent Browser.
Do not confuse that with the built-in Workbench Browser:
Long term, desktop browser tools should use the Workbench Browser session directly instead of launching an unrelated agent-browser session.
Current relevant files:
packages/desktop/src/workbench-browser.ts — Electron browser view controller, validation, snapshots, screenshots, commentspackages/desktop/src/window.ts — owns the browser controller and routes window-scoped operationspackages/desktop/src/ipc.ts and packages/desktop/src/preload.ts — bridge browser operations/eventspackages/desktop/server/extensions/workbenchBrowserAgentExtension.ts — Pi tool registration for browser_snapshot, browser_cdp, and browser_screenshotpackages/desktop/ui/src/components/Layout.tsx — Workbench Browser UI and comment overlaypackages/desktop/ui/src/pages/ConversationPage.tsx — pending browser comments in the composer and prompt context injectionKeep changes scoped. The Browser tab is part of Workbench layout, not a new standalone app shell.