بنقرة واحدة
dogfood
Exploratory QA of web apps: find bugs, evidence, reports.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Exploratory QA of web apps: find bugs, evidence, reports.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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.