Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/abdurrafay2004/handoff/browser-qanpx skills add AbdurRafay2004/handoff --skill browser-qagit clone --depth 1 https://github.com/AbdurRafay2004/handoffWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/abdurrafay2004/handoff/browser-qa)<a href="https://agentmods.dev/skills/abdurrafay2004/handoff/browser-qa"><img src="https://agentmods.dev/badge/skills/abdurrafay2004/handoff/browser-qa.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00085 | $0.02680 |
| Opus 5 | $0.00043 | $0.01340 |
| Sonnet 5 | $0.00017 | $0.00536 |
| Haiku 4.5 | $0.00009 | $0.00268 |
Grade A, and why
browser-qa scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
| API handler (`app/api/**`, `src/api/**`) | Hit the endpoint directly (fetch in the script or `curl`), plus the page that calls it | How it starts
The opening of the file, as written. The whole thing — 211 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Browser QA: exercise the running app, report what breaks
Part of the Verify phase — see the workflow skill for tiers and sequencing.
You are a QA engineer. Test the app like a real user — load the pages this change touched, click what a user would click, watch the console. Produce a report with evidence. NEVER fix anything. Fixes go through the normal Build/Verify loop (see Report-only discipline at the end).
Tier plan
Match effort to the tier the workflow skill assigned (or infer from the change's risk):
| Tier | What to do |
|---|---|
| T1 (typo, comment, config-only) | Skip browser QA entirely. Say so and stop. |
| T2 (normal features, including refactors; bug fixes) | Smoke the affected routes only: load, console clean, no failed requests, screenshot, one DOM assert per route. |
| T3 (money, auth, user data, migrations — or pre-ship of such work) | Full plan: affected routes plus adjacent routes and the top navigation targets, per-page checklist on each, health score with all categories. |
Every run — even T2 — ends with a health score and the plain-language summary.
Scope: derive routes from the diff
Test what changed, not the whole site. From git diff main...HEAD --name-only and
git log main..HEAD --oneline, map changed files to routes:
A multi-route QA run is token-heavy — a delegate trigger. Ask the user delegate-or-inline before running it (
delegateskill).
| Changed file | Routes to test |
|---|---|
Route/page file (app/**/page.tsx, pages/foo.tsx, src/pages/foo.astro) |
The route it serves (/foo) |
| Shared component | Grep for importers; test the routes that render them |
| Layout, global CSS, providers | Every route inherits it — test homepage + one route per layout |
API handler (app/api/**, src/api/**) |
Hit the endpoint directly (fetch in the script or curl), plus the page that calls it |
| Model/service/lib code | Routes whose pages call into it |
| Backend/config/infra with no obvious route | Do NOT skip — smoke homepage + top 5 nav targets; backend changes still break pages |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 211 lines · 85 tokens per session scan A 4b12c0ecfded
browser-qa is a skill published in the GitHub repository AbdurRafay2004/handoff (4 stars, last pushed 1mo ago), licensed MIT. It adds 85 tokens to every session and 2,680 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
test-site
Tests a deployed, activated Power Pages site at runtime using browser-based navigation, page crawling, and API request verification via Playwright. Use when the user wants to test, verify, or smoke-test their deployed site.
qa
Browser-based QA verification. Launches a real browser, navigates the app, clicks buttons, fills forms, and tests user flows. Works as a standalone skill or as a phase end condition in campaigns. Requires Playwright (optional dependency, graceful skip if not installed).
11-browser-qa
Run post-review browser QA and produce short named videos for a locked happy path and sourced browser edge cases. Use when the user wants concise reviewer evidence for a web journey. Not for API, CLI, automated tests, diff review, or application fixes.
06-test
Write and iterate tests until they pass, or validate a user journey end to end in the browser. Use when the user wants to add coverage, find what's untested, or walk a flow. Not for auditing test health or debugging a failure.
browser-check
Drive a real browser and come back with a MEASUREMENT rather than an impression - console errors and >=400 responses as counts, computed styles as JSON when appearance is disputed. Use when work touches UI, when a review must verify one, or when fidelity-gate asks for its measurement.
symfony:e2e-panther-playwright
Write end-to-end tests with Symfony Panther 2.4 for browser automation or Playwright for complex scenarios.