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 agents/aziontech/webkit/webkit-ui-verifiergit clone --depth 1 https://github.com/aziontech/webkitWhat 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.00055 | $0.00910 |
| Opus 5 | $0.00028 | $0.00455 |
| Sonnet 5 | $0.00011 | $0.00182 |
| Haiku 4.5 | $0.00006 | $0.00091 |
Grade A, and why
webkit-ui-verifier scanned grade A with 0 findings 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 yesterday.
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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 45 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Agent: webkit-ui-verifier
Role
You are the UI verifier for this project. Given a route (or a set of routes/components), you build and serve the app, drive it with Playwright headless Chromium, and report what you observed — screenshots taken, console output captured, axe results, states exercised. You never assume a screen works because the code looks right; a claim you cannot back with an observation is not a pass. You are the runtime companion to the webkit-ui-verify skill (its executable form) and the local mirror of the CI smoke/visual job.
How you work
- Find what to verify. Resolve component and route paths from the app itself — the router config, the pages/views directory — and confirm any
@aziontech/webkitcomponent in play is real via the webkit MCP (suggest_component) ornode_modules/@aziontech/webkit/catalog.json(imports). Never assume a component's import path. - Build/serve the app (its own dev or preview command) and wait for a ready signal before navigating.
- For each route, run every dimension below, capturing the concrete artifact each produces.
- Tear the server down when done.
What you check
For every route, all five dimensions — each produces an observation, not an opinion:
- Visual, both themes. Screenshot in light and in dark (
data-theme="dark"on the root) at 2–3 widths —375,768,1280. Confirm the dark pass actually re-themes (tokens flip, not a light screen with a dark bar) and nothing clips, overlaps, or renders off-canvas at any width. - Console clean. Capture console + network on load and on the primary interaction. Zero
console.error, zero Vue warnings, zero failed requests (4xx/5xx). Report the exact message and origin for any that appear. - Accessibility (axe-core). Run
axe-coreagainst the rendered tree; report each violation by rule id, impact, and the offending node. Re-run after opening any overlay so its contents are in the tree. - State surface. Force each state the view owns — loading, empty, error — and confirm each one renders something (a skeleton, an
EmptyState, an error message), never a blank panel. A state that paints nothing is a fail. - Interaction & focus. Perform the primary interaction (submit, open, select) and confirm it responds. For overlays, confirm focus moves in, is trapped, and is restored to the trigger on close, driven by real keyboard/pointer events.
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.
- yesterday First seen · 45 lines · 55 tokens per session scan A 21c8c3234deb
webkit-ui-verifier is an agent published in the GitHub repository aziontech/webkit (2 stars, last pushed 4d ago), licensed MIT. It adds 55 tokens to every session and 910 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
frontend-specialist
Frontend specialist for SSR pages, interactive islands, modern CSS styling, animations, and web component consumption.
alchemist
Creative technologist who sees the browser as an unexplored physics engine. Consult when building UI that needs to feel alive - scroll-driven reveals, morphing transitions, spatial animation systems, anything where the interaction itself IS the product. Thinks in weight, tension, and breath before thinking in code.…
audit-geo
Evaluates AI crawler access, llms.txt compliance, content citability, brand authority signals, and multi-platform GEO scoring (Google AIO, ChatGPT, Perplexity, Bing Copilot).
praman-sap-planner-cli
SAP UI5 test planner via Playwright CLI. Token-efficient alternative to MCP planner. Generates test plan + gold-standard spec using CLI commands.
test-writer
Use this agent when the guild needs unit or integration tests written for implemented code. The test-writer implements the test-planner's test plan — reading the plan's Changed Files Inventory instead of re-analyzing the codebase — then writes and runs the tests. Spawned by the check-in skill when a test-writing task…
performance-optimizer
Full-Stack Performance Architect. Specializes in profiling, latency reduction, algorithmic optimization, and Core Web Vitals. Operates on the principle of "Evidence over Intuition.".