Best for
- Use when asked to "dogfood", "QA", "exploratory test", "find issues", "bug hunt", "test this app/site/platform", or review the quality of a web application.
vercel-labs/agent-browser/skill-data/dogfood/SKILL.md
Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to "dogfood", "QA", "exploratory test", "find issues", "bug hunt", "test this app/site/platform", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams.
Decision brief
Systematically explore a web application, find issues, and produce a report with full reproduction evidence for every finding.
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/vercel-labs/agent-browser --skill "skill-data/dogfood"Inspect the Agent Skill "dogfood" from https://github.com/vercel-labs/agent-browser/blob/585e740fcef069d74e21f0e88e8bf4ea7df34385/skill-data/dogfood/SKILL.md at commit 585e740fcef069d74e21f0e88e8bf4ea7df34385. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
Only the Target URL is required. Everything else has sensible defaults -- use them unless the user explicitly provides an override.
Copy the report template into the output directory and fill in the header fields:
Copy the report template into the output directory and fill in the header fields:
If the app requires login:
agent-browser --session {SESSION} fill @e1 "{EMAIL}" agent-browser --session {SESSION} fill @e2 "{PASSWORD}" agent-browser --session {SESSION} click @e3 agent-browser --session {SESSION} wait --load networkidle bash agent-browser --session {SESSION} state save {OUTPUTDIR}/auth-s…
Permission review
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 92/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 41,273 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Systematically explore a web application, find issues, and produce a report with full reproduction evidence for every finding.
Only the Target URL is required. Everything else has sensible defaults -- use them unless the user explicitly provides an override.
| Parameter | Default | Example override |
|---|---|---|
| Target URL | (required) | vercel.com, http://localhost:3000 |
| Session name | Slugified domain (e.g., vercel.com -> vercel-com) | --session my-session |
| Output directory | ./dogfood-output/ | Output directory: /tmp/qa |
| Scope | Full app | Focus on the billing page |
| Authentication | None | Sign in to [email protected] |
If the user says something like "dogfood vercel.com", start immediately with defaults. Do not ask clarifying questions unless authentication is mentioned but credentials are missing.
Always use agent-browser directly -- never npx agent-browser. The direct binary uses the fast Rust client. npx routes through Node.js and is significantly slower.
1. Initialize Set up session, output dirs, report file
2. Authenticate Sign in if needed, save state
3. Orient Navigate to starting point, take initial snapshot
4. Explore Systematically visit pages and test features
5. Document Screenshot + record each issue as found
6. Wrap up Update summary counts, close session
mkdir -p {OUTPUT_DIR}/screenshots {OUTPUT_DIR}/videos
Copy the report template into the output directory and fill in the header fields:
cp {SKILL_DIR}/templates/dogfood-report-template.md {OUTPUT_DIR}/report.md
Start a named session:
agent-browser --session {SESSION} open {TARGET_URL}
agent-browser --session {SESSION} wait --load networkidle
If the app requires login:
agent-browser --session {SESSION} snapshot -i
# Identify login form refs, fill credentials
agent-browser --session {SESSION} fill @e1 "{EMAIL}"
agent-browser --session {SESSION} fill @e2 "{PASSWORD}"
agent-browser --session {SESSION} click @e3
agent-browser --session {SESSION} wait --load networkidle
For OTP/email codes: ask the user, wait for their response, then enter the code.
After successful login, save state for potential reuse:
agent-browser --session {SESSION} state save {OUTPUT_DIR}/auth-state.json
Take an initial annotated screenshot and snapshot to understand the app structure:
agent-browser --session {SESSION} screenshot --annotate {OUTPUT_DIR}/screenshots/initial.png
agent-browser --session {SESSION} snapshot -i
Identify the main navigation elements and map out the sections to visit.
Read references/issue-taxonomy.md for the full list of what to look for and the exploration checklist.
Strategy -- work through the app systematically:
At each page:
agent-browser --session {SESSION} snapshot -i
agent-browser --session {SESSION} screenshot --annotate {OUTPUT_DIR}/screenshots/{page-name}.png
agent-browser --session {SESSION} errors
agent-browser --session {SESSION} console
Use your judgment on how deep to go. Spend more time on core features and less on peripheral pages. If you find a cluster of issues in one area, investigate deeper.
Steps 4 and 5 happen together -- explore and document in a single pass. When you find an issue, stop exploring and document it immediately before moving on. Do not explore the whole app first and document later.
Every issue must be reproducible. When you find something wrong, do not just note it -- prove it with evidence. The goal is that someone reading the report can see exactly what happened and replay it.
Choose the right level of evidence for the issue:
These require user interaction to reproduce -- use full repro with video and step-by-step screenshots:
agent-browser --session {SESSION} record start {OUTPUT_DIR}/videos/issue-{NNN}-repro.webm
agent-browser --session {SESSION} screenshot {OUTPUT_DIR}/screenshots/issue-{NNN}-step-1.png
sleep 1
# Perform action (click, fill, etc.)
sleep 1
agent-browser --session {SESSION} screenshot {OUTPUT_DIR}/screenshots/issue-{NNN}-step-2.png
sleep 1
# ...continue until the issue manifests
sleep 2
agent-browser --session {SESSION} screenshot --annotate {OUTPUT_DIR}/screenshots/issue-{NNN}-result.png
agent-browser --session {SESSION} record stop
These are visible without interaction -- a single annotated screenshot is sufficient. No video, no multi-step repro:
agent-browser --session {SESSION} screenshot --annotate {OUTPUT_DIR}/screenshots/issue-{NNN}.png
Write a brief description and reference the screenshot in the report. Set Repro Video to N/A.
For all issues:
Append to the report immediately. Do not batch issues for later. Write each one as you find it so nothing is lost if the session is interrupted.
Increment the issue counter (ISSUE-001, ISSUE-002, ...).
Aim to find 5-10 well-documented issues, then wrap up. Depth of evidence matters more than total count -- 5 issues with full repro beats 20 with vague descriptions.
After exploring:
### ISSUE- block must be reflected in the totals.agent-browser --session {SESSION} close
snapshot -i — for finding clickable/fillable elements (buttons, inputs, links)snapshot (no flag) — for reading page content (text, headings, data lists)rm screenshots, videos, or the report mid-session. Do not close the session and restart. Work forward, not backward.type instead of fill -- it types character-by-character. Use fill only outside of video recording when speed matters.sleep 1 between actions and sleep 2 before the final result screenshot. Videos should be watchable at 1x speed -- a human reviewing the report needs to see what happened, not a blur of instant state changes.agent-browser commands in a single shell call when they are independent (e.g., agent-browser ... screenshot ... && agent-browser ... console). Use agent-browser --session {SESSION} scroll down 300 for scrolling -- do not use key or evaluate to scroll.| Reference | When to Read |
|---|---|
| references/issue-taxonomy.md | Start of session -- calibrate what to look for, severity levels, exploration checklist |
| Template | Purpose |
|---|---|
| templates/dogfood-report-template.md | Copy into output directory as the report file |
Frequently asked questions
Systematically explore a web application, find issues, and produce a report with full reproduction evidence for every finding.
The source record exposes this install command: npx skills add https://github.com/vercel-labs/agent-browser --skill "skill-data/dogfood". Inspect the command and pinned source before running it.
Alternatives
yonatangross/orchestkit
Grade work that already exists and decide whether it can merge. Runs the project's current unit, integration, and E2E suites plus security scanning and type checking, scores every dimension 0-10, and returns a merge verdict with a VERIFIED-vs-CLAIMED evidence manifest. Writes no test files and edits no source. Use when verifying changes are ready to merge. Use /ork:cover instead when the tests still have to be written.
microsoft/Sico
Execute Android UI workflows on a sandbox device, review results, and produce a structured execution report.
laurigates/claude-plugins
Analyze test results and create a fix plan with subagents. Use when triaging failing tests, analyzing JUnit XML, planning fixes for accessibility/security, or categorizing flaky/E2E failures.
mgiovani/cc-arsenal
Multi-agent review team: architecture, security, performance, testing, style, docs/UX, plus an adversary that cross-examines the other 6, for security-sensitive, architectural, or large PRs (15+ files) where a single-agent pass risks missing cross-cutting issues. Use for auth/payments/PII changes, schema/pattern changes, compliance sign-off, or when asked to 'get the review team on this' / 'multi-agent review' / 'thorough review before merge'. For a standard PR or a quick pre-merge check, use /r