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 Jewgah/claude-code-skills --skill frontend-verifygit clone --depth 1 https://github.com/Jewgah/claude-code-skillsWrote 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/jewgah/claude-code-skills/frontend-verify)<a href="https://agentmods.dev/skills/jewgah/claude-code-skills/frontend-verify"><img src="https://agentmods.dev/badge/skills/jewgah/claude-code-skills/frontend-verify/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/jewgah/claude-code-skills/frontend-verify"><img src="https://agentmods.dev/badge/skills/jewgah/claude-code-skills/frontend-verify.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.00163 | $0.02404 |
| Opus 5.5 | $0.00065 | $0.00962 |
| Sonnet 5.5 | $0.00033 | $0.00481 |
| Haiku 4.5 | $0.00016 | $0.00240 |
Grade A, and why
frontend-verify 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 1mo 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.
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.
This is a copy
100% identical to frontend-verify — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 274 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Frontend Verify
What this replaces
The slow loop is: edit code, start the dev server, open a browser, click each
page, watch the console, eyeball the layout, repeat. This skill does that pass
programmatically with @playwright/cli running headless, and it does it without
dumping every page state into the model context.
The one principle that matters
Reading a full accessibility snapshot or a screenshot into context on every route is the expensive part, not running the browser. So the order of operations is always cheapest signal first:
- Console errors and failed network requests. Tiny text, catches most real breakage (crashed component, bad fetch, 500 from an API route).
- Targeted text assertions. Ask the page "is the word Dashboard on screen", not "give me the whole DOM".
- A snapshot written to disk, read back only for a route that already failed.
- A screenshot, only as a last resort.
verify-routes.mjs runs steps 1 and 2 across all changed routes in one browser
pass, writes the detail to disk, and prints a compact PASS / WARN / FAIL table.
You read the table, then open detail files for flagged routes only. Do not read
detail for routes that passed.
When to take a screenshot
Almost never. Reach for one only when:
- A route is canvas, WebGL, or PixiJS. The accessibility tree is blind to pixels drawn on a canvas, so text and console checks cannot see the actual render.
- You are chasing a visual or layout regression (overlap, spacing, z-index, styling) that text cannot describe.
- The user explicitly asks to see the page.
For everything else, the console plus a text assertion tells you whether the page works. A screenshot tells you how it looks, which is a different and more expensive question.
Setup check
Confirm the CLI is installed before running anything:
playwright-cli --help
If that fails, the user installs it once with (PowerShell):
npm install -g @playwright/cli@latest
playwright-cli install-browser chrome-for-testing
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 1mo ago First seen · 274 lines · 163 tokens per session scan A ae67329cc35b
frontend-verify is a skill published in the GitHub repository Jewgah/claude-code-skills (2 stars, last pushed 2d ago), licensed MIT. It adds 163 tokens to every session and 2,404 once invoked, about $0.0007 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 100% identical to frontend-verify, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
specification-compliance-review
Use this skill when an implementation is described as partial, passing, or complete and the task is to determine whether it actually satisfies an explicit specification. This is not a generic code review and not a re-run of the test suite. The central question is: does every normative requirement have both a correct…
test-conversion-reviewer
Reviewer for converting unit tests to browser tests for Project Bedrock. Invoke this when the user needs to review their work while removing complex Browser dependencies from tests.
web-test
A browser-automation tool for testing the 1C:Enterprise web client. It uses Playwright to navigate sections, fill forms, read tables and reports, and perform user actions in a browser.
actionbook-web-test
Run browser-based web tests against websites using Actionbook CLI. Activate when the user wants to test a website workflow, run smoke tests, verify a user flow, check if a web application works, run regression tests, or validate browser-based interactions. Supports test definition, execution, assertion, reporting, and…
testing-blocks
Use this when you have made AEM Edge Delivery Services code changes to blocks, scripts, or styles and need to validate them before opening a pull request. Covers unit testing for utilities and logic, browser testing with Playwright, linting, and guidance on what to test and how.
acceptance-test-authoring
Use when creating or modifying acceptance tests, configuring cucumber-js or behave runners, writing or refactoring step definitions, linting executable Gherkin specs, choosing an acceptance stack, or implementing OpenSpec tasks that involve acceptance tests.