hermes-config/skills/dogfood/SKILL.md

name, description, version, platforms, metadata

name	description	version	platforms	metadata
dogfood	Exploratory QA of web apps: find bugs, evidence, reports.	1.0.0	linux macos windows	hermes tags related_skills qa testing browser web dogfood

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:

1. Target URL — the entry point for testing
2. Scope — what areas/features to focus on (or "full site" for comprehensive testing)
3. Output directory (optional) — where to save screenshots and the report (default: ./dogfood-output)

Workflow

Follow this 5-phase systematic workflow:

Phase 1: Plan

1. Create the output directory structure:

   {output_dir}/
   ├── screenshots/       # Evidence screenshots
   └── report.md          # Final report (generated in Phase 5)
   

2. Identify the testing scope based on user input.
3. 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:

1. Navigate to the page:

   browser_navigate(url="https://example.com/page")
   

2. Take a snapshot to understand the DOM structure:

   browser_snapshot()
   

3. 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.

4. 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=true flag overlays numbered [N] labels on interactive elements. Each [N] maps to ref @eN for subsequent browser commands.

5. 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

6. After each interaction, check for:

   • Console errors: browser_console()
   • Visual changes: browser_vision(question="What changed after the interaction?")
   • Expected vs actual behavior

Phase 3: Collect Evidence

For every issue found:

1. Take a screenshot showing the issue:

   browser_vision(question="Capture and describe the issue visible on this page", annotate=false)
   

   Save the screenshot_path from the response — you will reference it in the report.

2. Record the details:

   • URL where the issue occurs
   • Steps to reproduce
   • Expected behavior
   • Actual behavior
   • Console errors (if any)
   • Screenshot path

3. 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

1. Review all collected issues.
2. De-duplicate — merge issues that are the same bug manifesting in different places.
3. Assign final severity and category to each issue.
4. Sort by severity (Critical first, then High, Medium, Low).
5. 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:

1. Executive summary with total issue count, breakdown by severity, and testing scope
2. 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
3. Summary table of all issues
4. 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

Pitfalls

browser_vision model incompatibility

Some models (including deepseek-v4-pro, deepseek-v4-flash) do not support image inputs. Calling browser_vision() with these models returns an error like unknown variant 'image_url', expected 'text'. The screenshot is still captured at the screenshot_path in the response — you can reference it via MEDIA:<path> in your report even though the AI analysis failed.

When this happens, fall back to browser_snapshot(full=true) instead of retrying. Snapshot gives you the full accessibility tree with all interactive elements and their refs — it's actually more reliable than vision for click targeting since the @eN refs are deterministic.

Only use browser_vision when you need visual judgement (layout issues, color problems, image rendering). For element discovery and click targeting, snapshot alone is faster, cheaper, and works on every model.

Auth-gated sites

When the target site sits behind authentication, plan the auth bypass before Phase 2. Options in order of preference:

1. Ask the user for credentials if they own the site.
2. Create a test user via the backend API — for PocketBase-backed apps, call the collections API directly (e.g. POST /api/collections/users/records with email + password) since user creation is often public. Then use those credentials to log in via the browser.
3. Read login.js / auth code from the filesystem to understand the auth flow before attempting browser login. Static analysis saves browser tool turns.

Tips

• Always check browser_console() after navigating and after significant interactions. Silent JS errors are among the most valuable findings.
• Prefer browser_snapshot over browser_vision for element discovery. Snapshot gives you ref IDs (@eN) that are deterministic for clicking — vision's annotated labels can shift between calls. Reserve vision for visual-only assessments.
• 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.
• Discover the real URL before navigating. Check nginx configs (/etc/nginx/sites-enabled/), check for port conflicts (two server blocks on the same port), and verify with curl -H "Host: ..." before burning browser turns on wrong URLs. A 30-second curl check saves 3+ failed browser_navigate calls.