Directory → SKILL
SKILLbundledHermes Bundled Skills

Dogfood

Exploratory QA of web apps: find bugs, evidence, reports

qatestingbrowserwebdogfoodBundledHermes skill
Last registry verification2026-08-18v1.0.0Teknium (teknium1), Hermes Agent
Plain meaning

What does it add to Hermes?

Exploratory QA of web apps: find bugs, evidence, reports

Dogfood is a skill related to the web and browser automation. It can let the agent open pages, read websites, or perform browser steps, depending on the tools the resource exposes.

This plain-language explanation is based on the publisher description. The original text remains visible for verification.

Use it when

Use it when your goal in the web and browser automation is clear and you can limit it to the data and actions it actually needs.

Skip it when

Do not add it merely to experiment when Hermes already has a simpler path, or when you cannot review its source and permissions.

Who is it for?

Best for users who want a repeatable way of working inside Hermes.

Safe first test

Start on a public site without signing in, and extract one heading before allowing clicks or typing.

Original publisher description

Exploratory QA of web apps: find bugs, evidence, reports

✓
Data source

This entry was indexed from Hermes Bundled Skills. Our explanation interprets the type and domain without inventing a capability not present upstream.

!
Security review

The source is official or editorially reviewed, but you still need to review permissions and version compatibility.

Safe setup path

Inspect, install, then test.

  1. 01
    Open the source

    Match the publisher, license, and description to your need. Check the real update history.

  2. 02
    Review permissions and secrets

    Never paste a secret value into this site. Use environment-variable names and grant the smallest scope.

  3. 03
    Copy setup only after review

    The controls below copy text. They do not execute commands on your device.

  4. 04
    Test with a non-sensitive task

    Inspect the visible tools, then exclude write or delete tools you do not need.

Setup method

Already installed with Hermes.

This skill ships with Hermes and loads when the agent decides it is relevant. There is nothing to install; read the definition below so you know what it will do.

Open the official page ↗
The full skill definition

Exactly what Hermes loads when this skill runs.

Reproduced from the official documentation. Read it before enabling the skill: this text becomes the agent's instructions.

Exploratory QA of web apps: find bugs, evidence, reports.

Skill metadata

A lookup table. Do not read it all; find the row that applies to you.

SourceBundled (installed by default)
Pathskills/software-development/dogfood
Version1.0.0
AuthorTeknium (teknium1), Hermes Agent
LicenseMIT
Platformslinux, macos, windows
Tagsqa, testing, browser, web, dogfood

Reference: full SKILL.md

Explains the idea itself. Read it slowly; the later sections build on it.

Overview

Explains the idea itself. Read it slowly; the later sections build on it.

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

Explains the idea itself. Read it slowly; the later sections build on it.

  • 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

Explains the idea itself. Read it slowly; the later sections build on it.

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

Explains the idea itself. Read it slowly; the later sections build on it.

Follow this 5-phase systematic workflow:

Phase 1: Plan

  1. Create the output directory structure:
Text3 lines
   {output_dir}/
   ├── screenshots/       # Evidence screenshots
   └── report.md          # Final report (generated in Phase 5)
  1. Identify the testing scope based on user input.
  2. Build a rough sitemap by planning which pages and features to test:
  3. Landing/home page
  4. Navigation links (header, footer, sidebar)
  5. Key user flows (sign up, login, search, checkout, etc.)
  6. Forms and interactive elements
  7. Edge cases (empty states, error pages, 404s)

Phase 2: Explore

For each page or feature in your plan:

  1. Navigate to the page:
Text1 line
   browser_navigate(url="https://example.com/page")
  1. Take a snapshot to understand the DOM structure:
Text1 line
   browser_snapshot()
  1. Check the console for JavaScript errors:
Text1 line
   browser_console(clear=true)

Do this after every navigation and after every significant interaction. Silent JS errors are high-value findings.

  1. Take an annotated screenshot to visually assess the page and identify interactive elements:
Text1 line
   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.

  1. Test interactive elements systematically:
  2. Click buttons and links: browser_click(ref="@eN")
  3. Fill forms: browser_type(ref="@eN", text="test input")
  4. Test keyboard navigation: browser_press(key="Tab"), browser_press(key="Enter")
  5. Scroll through content: browser_scroll(direction="down")
  6. Test form validation with invalid inputs
  7. Test empty submissions
  1. After each interaction, check for:
  2. Console errors: browser_console()
  3. Visual changes: browser_vision(question="What changed after the interaction?")
  4. Expected vs actual behavior

Phase 3: Collect Evidence

For every issue found:

  1. Take a screenshot showing the issue:
Text1 line
   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.

  1. Record the details:
  2. URL where the issue occurs
  3. Steps to reproduce
  4. Expected behavior
  5. Actual behavior
  6. Console errors (if any)
  7. Screenshot path
  1. Classify the issue using the issue taxonomy (see references/issue-taxonomy.md):
  2. Severity: Critical / High / Medium / Low
  3. 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:
  3. Issue number and title
  4. Severity and category badges
  5. URL where observed
  6. Description of the issue
  7. Steps to reproduce
  8. Expected vs actual behavior
  9. Screenshot references (use MEDIA:<screenshot_path> for inline images)
  10. Console errors if relevant
  11. Summary table of all issues
  12. Testing notes — what was tested, what was not, any blockers

Save the report to {output_dir}/report.md.

Tools Reference

A lookup table. Do not read it all; find the row that applies to you.

ToolPurpose
browser_navigateGo to a URL
browser_snapshotGet DOM text snapshot (accessibility tree)
browser_clickClick an element by ref (@eN) or text
browser_typeType into an input field
browser_scrollScroll up/down on the page
browser_backGo back in browser history
browser_pressPress a keyboard key
browser_visionScreenshot + AI analysis; use annotate=true for element labels
browser_consoleGet JS console output and errors

Tips

Explains the idea itself. Read it slowly; the later sections build on it.

  • Always check browser_console() after navigating and after significant interactions. Silent JS errors are among the most valuable findings.
  • Use annotate=true with browser_vision when 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.