dogfood
Skill247 starsChanged 10 days agoMITView on GitHub
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.
We split this skill into the rules it gives an agent
20 rules. 0 are common, 15 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 72 edited versions we read keep these.
15
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
Only the Target URL is required.
- Distinctive: line 31
If the user says something like "dogfood vercel.com", start immediately with defaults.
- Very specific: line 33
Always use agent-browser directly -- never npx agent-browser.
- Distinctive: line 58
Start a named session:
- Distinctive: line 67
If the app requires login:
- Distinctive: line 80
After successful login, save state for potential reuse:
- Distinctive: line 99
Read references/issue-taxonomy.md for the full list of what to look for and the exploration checklist.
- Distinctive: line 103
Start from the main navigation.
- Distinctive: line 105
Check edge cases: empty states, error handling, boundary inputs.
- Distinctive: line 107
Check the browser console for errors periodically.
- Distinctive: line 118
Use your judgment on how deep to go.
- Distinctive: line 124
Every issue must be reproducible.
- Distinctive: line 163
Write numbered repro steps in the report, each referencing its screenshot.
- Very specific: line 173
Write a brief description and reference the screenshot in the report.
- Distinctive: line 179
Append to the report immediately: Do not batch issues for later.
- Distinctive: line 200
Repro is everything: Every issue needs proof -- but match the evidence to the issue.
- Distinctive: line 201
Verify reproducibility before collecting evidence: Before recording video or taking screenshots, verify the issue is reproducible with at …
- Very specific: line 210
Never delete output files: Do not rm screenshots, videos, or the report mid-session.
- Very specific: line 214
Type like a human: When filling form fields during video recording, use type instead of fill -- it types character-by-character.
- Very specific: line 215
Pace repro videos for humans: Add sleep 1 between actions and sleep 2 before the final result screenshot.
“Common” is measured: kept by at least 6 in 10 of the 72 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!--
Derived from vercel-labs/agent-browser (skills/dogfood/SKILL.md).
Copyright 2025 Vercel Inc. Licensed under Apache-2.0.
Modified by ZCode: local integration, formatting and adaptations.
See THIRD-PARTY-NOTICES.md in the repository root for license and provenance.
-->Dogfood
Systematically explore a web application, find issues, and produce a report with full reproduction evidence for every finding.
Setup
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 user@example.com |
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.
Workflow
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 session1. Initialize
mkdir -p {OUTPUT_DIR}/screenshots {OUTPUT_DIR}/videosCopy the report template into the output directory and fill in the header fields:
cp {SKILL_DIR}/templates/dogfood-report-template.md {OUTPUT_DIR}/report.mdStart a named session:
agent-browser --session {SESSION} open {TARGET_URL}
agent-browser --session {SESSION} wait --load networkidle2. Authenticate
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 networkidleFor 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.json3. Orient
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 -iIdentify the main navigation elements and map out the sections to visit.
4. Explore
Read references/issue-taxonomy.md for the full list of what to look for and the exploration checklist.
Strategy -- work through the app systematically:
- Start from the main navigation. Visit each top-level section.
- Within each section, test interactive elements: click buttons, fill forms, open dropdowns/modals.
- Check edge cases: empty states, error handling, boundary inputs.
- Try realistic end-to-end workflows (create, edit, delete flows).
- Check the browser console for errors periodically.
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} consoleUse 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.
5. Document Issues (Repro-First)
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:
Interactive / behavioral issues (functional, ux, console errors on action)
These require user interaction to reproduce -- use full repro with video and step-by-step screenshots:
- Start a repro video before reproducing:
agent-browser --session {SESSION} record start {OUTPUT_DIR}/videos/issue-{NNN}-repro.webm- Walk through the steps at human pace. Pause 1-2 seconds between actions so the video is watchable. Take a screenshot at each step:
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- Capture the broken state. Pause so the viewer can see it, then take an annotated screenshot:
sleep 2
agent-browser --session {SESSION} screenshot --annotate {OUTPUT_DIR}/screenshots/issue-{NNN}-result.png- Stop the video:
agent-browser --session {SESSION} record stop- Write numbered repro steps in the report, each referencing its screenshot.
Static / visible-on-load issues (typos, placeholder text, clipped text, misalignment, console errors on load)
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}.pngWrite 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, ...).
6. Wrap Up
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:
- Re-read the report and update the summary severity counts so they match the actual issues. Every
### ISSUE-block must be reflected in the totals. - Close the session:
agent-browser --session {SESSION} close- Tell the user the report is ready and summarize findings: total issues, breakdown by severity, and the most critical items.
Guidance
- Repro is everything. Every issue needs proof -- but match the evidence to the issue. Interactive bugs need video and step-by-step screenshots. Static bugs (typos, placeholder text, visual glitches visible on load) only need a single annotated screenshot.
- Verify reproducibility before collecting evidence. Before recording video or taking screenshots, verify the issue is reproducible with at least one retry. If it can't be reproduced consistently, it's not a valid issue.
- Don't record video for static issues. A typo or clipped text doesn't benefit from a video. Save video for issues that involve user interaction, timing, or state changes.
- For interactive issues, screenshot each step. Capture the before, the action, and the after -- so someone can see the full sequence.
- Write repro steps that map to screenshots. Each numbered step in the report should reference its corresponding screenshot. A reader should be able to follow the steps visually without touching a browser.
- Use the right snapshot command.
snapshot -i— for finding clickable/fillable elements (buttons, inputs, links)snapshot(no flag) — for reading page content (text, headings, data lists)
- Be thorough but use judgment. You are not following a test script -- you are exploring like a real user would. If something feels off, investigate.
- Write findings incrementally. Append each issue to the report as you discover it. If the session is interrupted, findings are preserved. Never batch all issues for the end.
- Never delete output files. Do not
rmscreenshots, videos, or the report mid-session. Do not close the session and restart. Work forward, not backward. - Never read the target app's source code. You are testing as a user, not auditing code. Do not read HTML, JS, or config files of the app under test. All findings must come from what you observe in the browser.
- Check the console. Many issues are invisible in the UI but show up as JS errors or failed requests.
- Test like a user, not a robot. Try common workflows end-to-end. Click things a real user would click. Enter realistic data.
- Type like a human. When filling form fields during video recording, use
typeinstead offill-- it types character-by-character. Usefillonly outside of video recording when speed matters. - Pace repro videos for humans. Add
sleep 1between actions andsleep 2before 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. - Be efficient with commands. Batch multiple
agent-browsercommands in a single shell call when they are independent (e.g.,agent-browser ... screenshot ... && agent-browser ... console). Useagent-browser --session {SESSION} scroll down 300for scrolling -- do not usekeyorevaluateto scroll.
References
| Reference | When to Read |
| references/issue-taxonomy.md | Start of session -- calibrate what to look for, severity levels, exploration checklist |
Templates
| Template | Purpose |
| templates/dogfood-report-template.md | Copy into output directory as the report file |
Trending
Cooling: 3 new projects took it in the last 4 weeks, 0.8× the 4 weeks before.thin data
Other versions75 projects use a version of this.
Word for word · 3
- zai-org/ZCode★ 8.4k100% same
- skillpie/ZCodeOnline★ 3100% same
- betacatsling/Open-ZCode★ 0100% same
Edited · 15
- vercel-labs/agent-browser★ 45k97% same
- salesforce/cloudsplaining★ 2.3k98% same
- coder/cmux★ 2.1k94% same
- coder/mux★ 2.1k94% same
- phodal/routa★ 1.8k99% same
- gronxb/codex-relay★ 72519% same
- gmickel/gno★ 11799% same
- vobase/vobase★ 60100% same
- ccbud/CCBuddy★ 8100% same
- flpbalada/fb-skills★ 830% same
5 more not listed
Wrote their own version · 57
- NousResearch/hermes-agent★ 259ksame name
- coder/coder★ 17ksame name
- callstackincubator/agent-device★ 5.2ksame name
- callstack/agent-device★ 5.2ksame name
- math-inc/OpenGauss★ 1.3ksame name
- Tommy-yw/RunbookHermes★ 546same name
- redf0x1/camofox-browser★ 435same name
- aivrar/portable-hermes-agent★ 239same name
- RedWoodOG/Hermes-Desktop★ 177same name
- paiml/paiml-mcp-agent-toolkit★ 168same name
47 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use yuanbao, minecraft-modpack-server and 7 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
lir-navcooSkillyuanbao
Yuanbao (元宝) groups: @mention users, query info/members.
Also in 17 projects that use this
math-incSkillminecraft-modpack-server
Set up a modded Minecraft server from a CurseForge/Modrinth server pack zip. Covers NeoForge/Forge install, Java version, JVM tuning, firewall, LAN config, backups, and launch scripts.
Also in 5 projects that use this
math-incSkillpokemon-player
Play Pokemon games autonomously via headless emulation. Starts a game server, reads structured game state from RAM, makes strategic decisions, and sends button inputs — all from the terminal.
Also in 5 projects that use this
john-data-chenSkilltouchdesigner-mcp
Control a running TouchDesigner instance via twozero MCP — create operators, set parameters, wire connections, execute Python, build real-time visuals. 36 native tools.
Also in 7 projects that use this
aivrarSkillcompetitor-news-monitor
Watch named companies for material news; cited digests.
Also in 7 projects that use this
aivrarSkilldocument-to-action-items
Extract cited obligations, deadlines, tasks from documents.
Also in 6 projects that use this
- +2 more from math-inc
In this repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .agents/skills/react-best-practices/AGENTS.mdAGENTS.md
- agent-browserSkill
- ai-elementsSkill
- architecture-governanceSkill
- dep-refsSkill
- docxSkill
- e2e-case-lifecycleSkill
- electronSkill
- feature-boundary-plannerSkill
- vercel-react-best-practicesSkill
- session-managementSkill
- xlsxSkill
- zcode-large-task-fixtureSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

