dogfood
nousresearch/hermes-agent
Systematic exploratory QA testing for web apps: find bugs, capture evidence, generate reports.
What is dogfood?
Dogfood is a structured skill for testing web applications through the browser, identifying bugs across functionality, visuals, accessibility, and console errors. Use it when you need to perform comprehensive QA on a target URL and produce a documented bug report with screenshots and reproduction steps.
- Navigate and explore web pages systematically across multiple features and user flows
- Capture annotated screenshots and DOM snapshots to identify interactive elements and visual issues
- Check JavaScript console for silent errors after every navigation and interaction
- Test interactive elements including buttons, forms, keyboard navigation, and validation
- Collect and categorize issues by severity (Critical/High/Medium/Low) and type (Functional/Visual/Accessibility/Console/UX/Content)
- Generate structured markdown bug reports with evidence, reproduction steps, and summary tables
How to install dogfood
npx skills add https://github.com/nousresearch/hermes-agent --skill dogfood- 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
How to use dogfood
- 1.Provide the target URL and testing scope (specific features or 'full site')
- 2.Follow Phase 1 to plan the testing scope and identify pages/features to test
- 3.Execute Phase 2 by navigating to each page, taking snapshots, checking console, and testing interactive elements systematically
- 4.In Phase 3, capture screenshots and record details for every issue found (URL, steps to reproduce, expected vs actual behavior, console errors)
- 5.Complete Phase 4 by reviewing, de-duplicating, and categorizing all issues by severity and type
- 6.Generate the final report in Phase 5 using the template, including executive summary, per-issue details with screenshots, and summary table
Use cases
- QA testing a new web application before launch to identify bugs across all major features
- Testing a redesigned website to catch visual regressions and broken functionality
- Validating form handling and error states across a multi-step user flow
- Checking accessibility and console errors on a live application
- Documenting bugs with screenshots and reproduction steps for a development team
- QA engineers and testers
- Product managers validating new features
- Developers doing exploratory testing before release
- Technical stakeholders reviewing application quality
dogfood FAQ
Record it as a high-value finding. Always check `browser_console()` after navigating and after significant interactions—silent JS errors are among the most valuable QA discoveries.
Use `browser_vision(question="...", annotate=true)` to get a screenshot with numbered labels `[N]` overlaid on interactive elements. Each label maps to a ref `@eN` that you can use in subsequent `browser_click()` or `browser_type()` commands.
In Phase 4, de-duplicate by merging issues that are the same bug manifesting in different places. Each unique bug gets one entry in the final report, but note all URLs where it occurs.
Yes. Test forms with both valid and invalid inputs, empty submissions, very long text, special characters, and rapid clicking. Also test empty states and error pages—these commonly reveal bugs.
Save the `screenshot_path` from each `browser_vision()` call, then reference it in the report using the format `MEDIA:<screenshot_path>` so screenshots appear inline in the markdown report.
Full instructions (SKILL.md)
Source of truth, from nousresearch/hermes-agent.
name: dogfood description: "Exploratory QA of web apps: find bugs, evidence, reports." version: 1.0.0 author: Teknium (teknium1), Hermes Agent license: MIT platforms: [linux, macos, windows] metadata: hermes: tags: [qa, testing, browser, web, dogfood] related_skills: []
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:
browser_console(clear=true)Do this after every navigation and after every significant interaction. Silent JS errors are high-value findings.
-
Take an annotated screenshot to visually assess the page and identify interactive elements:
browser_vision(question="Describe the page layout, identify any visual issues, broken elements, or accessibility concerns", annotate=true)The
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:
browser_vision(question="Capture and describe the issue visible on this page", annotate=false)Save the
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.
Related skills
More from nousresearch/hermes-agent and the wider catalog.

distill-memory
Capture breakthrough moments and valuable insights as searchable memories in your knowledge base.

read-working-memory
Read your daily Working Memory briefing to understand current context. Contains active focus areas, priorities, unresolved flags, and recent knowledge changes. Load this automatically at the beginning of sessions for cross-tool continuity.

save-thread
Deprecated compatibility skill. In generic npx skills environments this must degrade honestly to a resumable handoff, because real transcript-backed thread import is not guaranteed. Prefer save-handoff here, and use native connectors when you need actual session capture.

search-memory
Search your personal knowledge base when past insights would improve response. Recognize when stored breakthroughs, decisions, or solutions are relevant. Search proactively based on context, not just explicit requests.

Nia
Index and search code repos, docs, papers, datasets, Slack, Drive, and more with unified API access.

link-workspace-packages
Link workspace packages in monorepos using npm, yarn, pnpm, or bun.