com um clique
dogfood
Exploratory QA of web apps: find bugs, evidence, reports.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Exploratory QA of web apps: find bugs, evidence, reports.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Configure official native OpenCode to add a local LiteLLM OpenAI-compatible Gemini model as a selectable provider using config-file secret references, without wrappers and without changing the current default model.
Diagnose and repair a local LiteLLM + Vertex AI proxy on macOS, especially when `http://127.0.0.1:4000/` or `/v1` is down, startup hangs at `Waiting for application startup`, `/ui/login/` says `Authentication Error, Not connected to DB!`, or Prisma/PostgreSQL issues need to be isolated from the API proxy by splitting `lite` and `full` modes.
Configure an existing Hermes Agent deployment to use a local LiteLLM Vertex Proxy as an additional model option, without disturbing the current Hermes configuration. Use when you need Hermes to access Gemini models via a local LiteLLM gateway already running at 127.0.0.1:4000.
Configure OpenClaw to use an already-running local LiteLLM gateway for Gemini on macOS, with a low-risk add-as-option workflow, exact openclaw.json snippets, verification commands, rollback steps, and the real caveat that some per-run model overrides are rejected unless you use --local or switch the active alias first.
Build a local macOS LiteLLM gateway that exposes Google Cloud Vertex AI Gemini behind an Anthropic-compatible endpoint, then connect Claude Code and OpenClaw to it without breaking existing setups. Use when starting from a fresh machine, when you need a self-starting LaunchAgent service on 127.0.0.1, when Claude Code should route through LiteLLM, or when OpenClaw needs a selectable Gemini-via-LiteLLM model.
Fix packaging and validation failures caused by fragile SKILL frontmatter when publishing or syncing skills into Toby's davidtoby/agent-skills repository. Use when rebuild_all_packages.py fails early on a promoted skill, especially after copying local-only community skills such as lark-* into the repo.
| name | dogfood |
| description | Exploratory QA of web apps: find bugs, evidence, reports. |
| metadata | {"hermes":{"tags":["qa","testing","browser","web","dogfood"],"related_skills":[]}} |
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.
browser_navigate, browser_snapshot, browser_click, browser_type, browser_vision, browser_console, browser_scroll, browser_back, browser_press)The user provides:
./dogfood-output)Follow this 5-phase systematic workflow:
{output_dir}/
├── screenshots/ # Evidence screenshots
└── report.md # Final report (generated in Phase 5)
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=true flag overlays numbered [N] labels on interactive elements. Each [N] maps to ref @eN for subsequent browser commands.
Test interactive elements systematically:
browser_click(ref="@eN")browser_type(ref="@eN", text="test input")browser_press(key="Tab"), browser_press(key="Enter")browser_scroll(direction="down")After each interaction, check for:
browser_console()browser_vision(question="What changed after the interaction?")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_path from the response — you will reference it in the report.
Record the details:
Classify the issue using the issue taxonomy (see references/issue-taxonomy.md):
Generate the final report using the template at templates/dogfood-report-template.md.
The report must include:
MEDIA:<screenshot_path> for inline images)Save the report to {output_dir}/report.md.
| 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 |
browser_console() after navigating and after significant interactions. Silent JS errors are among the most valuable findings.annotate=true with browser_vision when you need to reason about interactive element positions or when the snapshot refs are unclear.MEDIA:<screenshot_path> so they can see the evidence inline.