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 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/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/abdurrafay2004/handoff/browser-qa"><img src="https://agentmods.dev/badge/skills/abdurrafay2004/handoff/browser-qa.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00085 | $0.02731 |
| Opus 5.5 | $0.00034 | $0.01092 |
| Sonnet 5.5 | $0.00017 | $0.00546 |
| Haiku 4.5 | $0.00009 | $0.00273 |
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 15d 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 — 216 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.
- 15d ago Changed · +5 lines d0c5dd21524f
- 1mo 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 10d ago), licensed MIT. It adds 85 tokens to every session and 2,731 once invoked, about $0.0003 per session on Opus 5.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).
06-test
Write and iterate developer-side tests until they pass, or validate a user journey end to end in the browser during implementation. Use when the user wants to add coverage, find what's untested, or walk a flow while building it. Do NOT use for independent acceptance QA or reviewer evidence, auditing test health, or…
proof-e2e
Build E2E test specs for critical user journeys — Playwright or Cypress, page objects, setup/teardown, CI config. Use when asked to "write E2E tests", "end-to-end testing", "browser tests", "UI tests", or "Playwright tests".
e2e-panther-playwright
Write end-to-end tests with Symfony Panther 2.4 for browser automation or Playwright for complex scenarios.
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.