Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/superagent-ai/grok-cli/agent-browsernpx skills add superagent-ai/grok-cli --skill agent-browsergit clone --depth 1 https://github.com/superagent-ai/grok-cliWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00031 | $0.00568 |
| Opus 5 | $0.00015 | $0.00284 |
| Sonnet 5 | $0.00006 | $0.00114 |
| Haiku 4.5 | $0.00003 | $0.00057 |
Grade A, and why
agent-browser scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 70 lines — stays where its author put it; the contents beside it link to each section on GitHub.
agent-browser
Use this skill when verification needs a real browser after the app is booted from the sandbox.
This project uses agent-browser on the host, not inside Shuru. The usual flow is:
- Start the app with sandboxed bash.
- Expose it through a forwarded localhost port.
- Use
agent-browseragainst that localhost URL.
Requirements
- The
agent-browserCLI must be installed and available onPATH. - Prefer
http://127.0.0.1:<port>or another explicit localhost URL. - Use a named browser session when there is any chance of concurrent runs.
Core flow
agent-browser --session verify open http://127.0.0.1:3000
agent-browser --session verify wait --load networkidle
agent-browser --session verify snapshot -i
After any click or navigation, re-snapshot before using old refs again.
Common commands
# Open and wait for readiness
agent-browser --session verify open <url>
agent-browser --session verify wait --load networkidle
# Inspect the page
agent-browser --session verify snapshot -i
agent-browser --session verify get title
agent-browser --session verify get url
# Interact with elements from snapshot refs
agent-browser --session verify click @e1
agent-browser --session verify fill @e2 "text"
agent-browser --session verify press Enter
# Record the smoke test as video
agent-browser record start .grok/verify-artifacts/verify-smoke.webm
# Capture screenshot proof (use --screenshot-dir, not a positional path)
mkdir -p .grok/verify-artifacts
agent-browser --screenshot-dir .grok/verify-artifacts screenshot
agent-browser --screenshot-dir .grok/verify-artifacts screenshot --full
# Stop recording and clean up
agent-browser record stop
agent-browser close
Guidance
- Keep browser checks narrow in phase 1: page load, one or two critical controls, and optional screenshot evidence.
- Save screenshots to stable workspace-relative paths under
.grok/verify-artifacts/so verify can report them back to the user. - Prefer
wait --load networkidleafteropen. - If the page is dynamic, use
snapshot -iagain after each meaningful DOM change. - If the target URL is ambiguous because multiple forwarded ports exist, stop and report the ambiguity instead of guessing.
- If
agent-browseris unavailable, fall back to bash-only verification and say so clearly.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 70 lines · 31 tokens per session scan A 34866c7bca14
agent-browser is a skill published in the GitHub repository superagent-ai/grok-cli (3,445 stars, last pushed 1mo ago), licensed MIT. It adds 31 tokens to every session and 568 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
playwright-cli
Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.
browser-testing-with-screenshots
Use when testing web applications with visual verification - automates Chrome browser interactions, element selection, and screenshot capture for confirming UI functionality.
smoke-test
Create a Mastra project using create-mastra and smoke test the studio in Chrome using Chrome MCP server.
playwright-e2e-testing
Author and maintain versioned Playwright (@playwright/test) TypeScript UI specs for browser user flows. Use when asked to create, run, debug, or refactor E2E tests, form/navigation/auth flows, responsive checks, UI mocking, fixtures, Page Objects, or visual comparisons. Use api-testing for standalone REST/GraphQL…
webapp-selenium-testing
Author and maintain versioned Selenium WebDriver tests with Java and JUnit 5. Use for creating, debugging, or running Selenium specs, implementing Page Objects, handling explicit waits, capturing screenshots, or setting up Maven test projects. Supports Chrome, Firefox, and Edge. Keywords: Selenium WebDriver, Java…
phoenix-pxi-playwright
Write, extend, and debug PXI Playwright E2E tests for Phoenix. Use when adding PXI agent frontend specs, authoring LLM-as-judge rubrics, asserting PXI tool use, persisting PXI test runs as Phoenix experiments, or debugging PXI E2E failures.