dogfood
Skill2 starsChanged 4 months agoMITView on GitHub
Exploratory QA of web apps: find bugs, evidence, reports.
We split this skill into the rules it gives an agent
7 rules. 0 are common, 4 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 61 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 32
Follow this 5-phase systematic workflow:
- Distinctive: line 36
Create the output directory structure:
- Distinctive: line 68
Do this after every navigation and after every significant interaction.
- Very specific: line 79
Test keyboard navigation: browser_press(key="Tab"), browser_press(key="Enter")
- Distinctive: line 81
Test form validation with invalid inputs
- Very specific: line 156
Use
annotate=truewithbrowser_vision: when you need to reason about interactive element positions or when the snapshot refs are … - Very specific: line 162
When reporting screenshots to the user, include MEDIA:<screenshot_path> so they can see the evidence inline.
“Common” is measured: kept by at least 6 in 10 of the 61 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
Dogfood: Systematic Web Application QA Testing
Overview
This skill guides you through systematic exploratory QA testing of web applications using the browser toolset. You will navigate the application, interact with elements, capture evidence of issues, and produce a structured bug report.
Prerequisites
- Browser toolset must be available (
browser_navigate,browser_snapshot,browser_click,browser_type,browser_vision,browser_console,browser_scroll,browser_back,browser_press) - A target URL and testing scope from the user
Inputs
The user provides:
- Target URL — the entry point for testing
- Scope — what areas/features to focus on (or "full site" for comprehensive testing)
- Output directory (optional) — where to save screenshots and the report (default:
./dogfood-output)
Workflow
Follow this 5-phase systematic workflow:
Phase 1: Plan
- Create the output directory structure:
{output_dir}/ ├── screenshots/ # Evidence screenshots └── report.md # Final report (generated in Phase 5) - Identify the testing scope based on user input.
- Build a rough sitemap by planning which pages and features to test:
- Landing/home page
- Navigation links (header, footer, sidebar)
- Key user flows (sign up, login, search, checkout, etc.)
- Forms and interactive elements
- Edge cases (empty states, error pages, 404s)
Phase 2: Explore
For each page or feature in your plan:
- Navigate to the page:
browser_navigate(url="https://example.com/page") - Take a snapshot to understand the DOM structure:
browser_snapshot() - Check the console for JavaScript errors:
Do this after every navigation and after every significant interaction. Silent JS errors are high-value findings.browser_console(clear=true) - Take an annotated screenshot to visually assess the page and identify interactive elements:
Thebrowser_vision(question="Describe the page layout, identify any visual issues, broken elements, or accessibility concerns", annotate=true)annotate=trueflag overlays numbered[N]labels on interactive elements. Each[N]maps to ref@eNfor subsequent browser commands. - Test interactive elements systematically:
- Click buttons and links:
browser_click(ref="@eN") - Fill forms:
browser_type(ref="@eN", text="test input") - Test keyboard navigation:
browser_press(key="Tab"),browser_press(key="Enter") - Scroll through content:
browser_scroll(direction="down") - Test form validation with invalid inputs
- Test empty submissions
- Click buttons and links:
- After each interaction, check for:
- Console errors:
browser_console() - Visual changes:
browser_vision(question="What changed after the interaction?") - Expected vs actual behavior
- Console errors:
Phase 3: Collect Evidence
For every issue found:
- Take a screenshot showing the issue:
Save thebrowser_vision(question="Capture and describe the issue visible on this page", annotate=false)screenshot_pathfrom the response — you will reference it in the report. - Record the details:
- URL where the issue occurs
- Steps to reproduce
- Expected behavior
- Actual behavior
- Console errors (if any)
- Screenshot path
- Classify the issue using the issue taxonomy (see
references/issue-taxonomy.md):- Severity: Critical / High / Medium / Low
- Category: Functional / Visual / Accessibility / Console / UX / Content
Phase 4: Categorize
- Review all collected issues.
- De-duplicate — merge issues that are the same bug manifesting in different places.
- Assign final severity and category to each issue.
- Sort by severity (Critical first, then High, Medium, Low).
- Count issues by severity and category for the executive summary.
Phase 5: Report
Generate the final report using the template at templates/dogfood-report-template.md.
The report must include:
- Executive summary with total issue count, breakdown by severity, and testing scope
- Per-issue sections with:
- Issue number and title
- Severity and category badges
- URL where observed
- Description of the issue
- Steps to reproduce
- Expected vs actual behavior
- Screenshot references (use
MEDIA:<screenshot_path>for inline images) - Console errors if relevant
- Summary table of all issues
- Testing notes — what was tested, what was not, any blockers
Save the report to {output_dir}/report.md.
Tools Reference
| Tool | Purpose |
browser_navigate | Go to a URL |
browser_snapshot | Get DOM text snapshot (accessibility tree) |
browser_click | Click an element by ref (@eN) or text |
browser_type | Type into an input field |
browser_scroll | Scroll up/down on the page |
browser_back | Go back in browser history |
browser_press | Press a keyboard key |
browser_vision | Screenshot + AI analysis; use annotate=true for element labels |
browser_console | Get JS console output and errors |
Tips
- Always check
browser_console()after navigating and after significant interactions. Silent JS errors are among the most valuable findings. - Use
annotate=truewithbrowser_visionwhen you need to reason about interactive element positions or when the snapshot refs are unclear. - Test with both valid and invalid inputs — form validation bugs are common.
- Scroll through long pages — content below the fold may have rendering issues.
- Test navigation flows — click through multi-step processes end-to-end.
- Check responsive behavior by noting any layout issues visible in screenshots.
- Don't forget edge cases: empty states, very long text, special characters, rapid clicking.
- When reporting screenshots to the user, include
MEDIA:<screenshot_path>so they can see the evidence inline.
Other versions75 projects use a version of this.
Word for word · 14
- delorenj/skills★ 16100% same
- Lord1Egypt/RA-Skills★ 8100% same
- aivos-xie/hermes-skills★ 1100% same
- daedalus/skills★ 1100% same
- lxt070409/hermes-skills★ 1100% same
- rickyananda/hermes-skills★ 1100% same
- 2867203296/hermes-agent★ 0100% same
- Air-0000/agent-skill★ 0100% same
- ishanbhosale08/Daedalus★ 0100% same
- jamesbmour/Hermes-Skills★ 0100% same
4 more not listed
Edited · 23
- NousResearch/hermes-agent★ 257k43% same
- math-inc/OpenGauss★ 1.3k96% same
- Tommy-yw/RunbookHermes★ 54698% same
- aivrar/portable-hermes-agent★ 23999% same
- RedWoodOG/Hermes-Desktop★ 17796% same
- AtlasOmnia/donna-starter★ 11585% same
- AtlasOmnia/hermes-custom-pack★ 6585% same
- itgoyo/hermes-skills★ 5398% same
- wundercorp/loki★ 2598% same
- lsjwzh/MultiCC★ 11100% same
13 more not listed
Wrote their own version · 38
- vercel-labs/agent-browser★ 45ksame name
- coder/coder★ 17ksame name
- zai-org/ZCode★ 7.9ksame name
- callstack/agent-device★ 5.1ksame name
- callstackincubator/agent-device★ 5.1ksame name
- salesforce/cloudsplaining★ 2.3ksame name
- coder/cmux★ 2.1ksame name
- coder/mux★ 2.1ksame name
- phodal/routa★ 1.8ksame name
- gronxb/codex-relay★ 692same name
28 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 dep-refs, feature-boundary-planner and 5 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.
betacatslingSkilldep-refs
Use when needs to inspect TypeScript export references in the z-code workspace, list exports from a file, verify whether an export is unused before deletion, investigate who imports a symbol during refactors, or combine pnpm knip unused-export results with pnpm dep:refs symbol-level reference tracing.
Also in 5 projects that use this
betacatslingSkillfeature-boundary-planner
Map a ZCode behavior change to current UI surfaces, state owners, protocol commands, persistence, and validation. Use for impact analysis, product-boundary planning, or an implementation handoff grounded in the checked-out source.
Also in 5 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
Cartograf666Skillarchitecture-governance
Bootstrap, document, enforce, and review a project's architecture through layer responsibilities, dependency direction, architecture manifests, legacy baselines, Change Envelopes, cross-layer approval policy, and deterministic architecture checks. Use when starting a project, auditing an existing codebase, planning cross-layer work, preventing architecture erosion, reviewing structural changes, or deciding whether implementation may expand into another layer.
Also in 5 projects that use this
aivrarSkillcompetitor-news-monitor
Watch named companies for material news; cited digests.
Also in 6 projects that use this
In this repository74 other files it gives its agents.
- apple-notesSkill
- apple-remindersSkill
- findmySkill
- imessageSkill
- claude-codeSkill
- codexSkill
- hermes-agentSkill
- opencodeSkill
- cavecrewSkill
- caveman-commitSkill
- caveman-compressSkill
- caveman-helpSkill
- caveman-reviewSkill
- cavemanSkill
- caveman-statsSkill
- computer-useSkill
- architecture-diagramSkill
- ascii-artSkill
- ascii-videoSkill
- baoyu-infographicSkill
- claude-designSkill
- comfyuiSkill
- design-mdSkill
- excalidrawSkill
- humanizerSkill
- manim-videoSkill
- p5jsSkill
- popular-web-designsSkill
- pretextSkill
- sketchSkill
- songwriting-and-ai-musicSkill
- touchdesigner-mcpSkill
- jupyter-live-kernelSkill
- hermes-config-backupSkill
- package-upgradeSkill
- himalayaSkill
- codebase-inspectionSkill
- github-authSkill
- github-code-reviewSkill
- github-issuesSkill
- github-pr-workflowSkill
- github-repo-managementSkill
- gif-searchSkill
- heartmulaSkill
- songseeSkill
- youtube-contentSkill
- huggingface-hubSkill
- obsidianSkill
- airtableSkill
- google-workspaceSkill
- mapsSkill
- nano-pdfSkill
- notionSkill
- ocr-and-documentsSkill
- petdexSkill
- powerpointSkill
- teams-meeting-pipelineSkill
- arxivSkill
- blogwatcherSkill
- llm-wikiSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

