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 niels-emmer/myace --skill visual-verification-workflowgit clone --depth 1 https://github.com/niels-emmer/myaceWrote 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/niels-emmer/myace/visual-verification-workflow)<a href="https://agentmods.dev/skills/niels-emmer/myace/visual-verification-workflow"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/visual-verification-workflow/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/niels-emmer/myace/visual-verification-workflow"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/visual-verification-workflow.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.00041 | $0.00696 |
| Opus 5 | $0.00020 | $0.00348 |
| Sonnet 5 | $0.00008 | $0.00139 |
| Haiku 4.5 | $0.00004 | $0.00070 |
Grade A, and why
Visual Verification Workflow 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 8d 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.
How it starts
The opening of the file, as written. The whole thing — 37 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
Reading a diff and believing it's correct is not the same as confirming it's correct. This skill is the concrete procedure for actually looking at a UI change running in a browser before reporting the task as finished — it's what backs the "never done without visual verification" rule.
When to use it
After any change that touches rendered UI: a new component, a style change, a layout change, new interactive behavior, or a fix to a visual bug. Skip it only for changes with no rendered surface at all (e.g. a pure backend/API change with no UI-visible effect).
Steps
-
Get it running. Start (or reuse) the dev server / preview environment for the app. If no browser or preview tool is available in the current environment, stop here and say so explicitly in your report — do not report the change as verified.
-
Check the golden path. Navigate to the actual screen/component affected and exercise the primary interaction the change was meant to support — click the button, submit the form, open the panel — not just a glance at the initial render. Confirm it behaves as intended, not merely that it renders without crashing.
-
Check at least one edge case. Pick whichever is most relevant to the change:
- Empty state — what does it look like with zero data/items?
- Long content — what happens with an unusually long string, a long list, or a large number where the design assumed something shorter?
- Mobile width — resize (or use device emulation) to a narrow viewport (roughly 375px) and confirm the layout still works: nothing overlaps, nothing is cut off, touch targets are still reasonably sized.
-
Check the console. Look at the browser console for errors or new warnings introduced by the change. A UI that looks fine but is quietly throwing errors is not done.
-
Check responsive and theme behavior where relevant. If the app supports multiple breakpoints, confirm the change holds up at both a narrow and a wide viewport. If the app supports light/dark mode, check the change in both — a common failure is text or borders that vanish in one theme because a color was hardcoded instead of using the theme's tokens.
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.
- 8d ago First seen · 37 lines · 41 tokens per session scan A e102a4873981
Visual Verification Workflow is a skill published in the GitHub repository niels-emmer/myace (1 stars, last pushed 5d ago), licensed MIT. It adds 41 tokens to every session and 696 once invoked, about $0.0002 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-09-03.
Other skills, from other repositories
loom-e2e-testing
End-to-end testing for web applications with Playwright, Cypress, Selenium, and Puppeteer.
use-workflow-pageshot
A pull-request helper that reads a preview link and test steps, then uses a browser to capture a screenshot or video of the tested page.
next-cache-components-optimizer
Drive a Next.js route to instant navigation by setting up an agentic loop, under Cache Components / PPR, on initial load (hard navigation) and client-side navigation (soft navigation). Encode the goal as a failing @next/playwright instant() e2e and work it to green, one verified route at a time; the shipped test then…
next-dev-loop
Verify Next.js runtime behavior after editing app code. Use this skill to confirm a change actually works in a running app — not just that it compiles or type-checks. Combines /next/mcp (Next.js's view) with agent-browser (the browser's view). Requires a running next dev.
playwright-component-testing
Set up component testing with Playwright using a story gallery — scaffold stories and a gallery dev page driven by the built-in mount fixture, no dedicated component-testing runtime. Use when asked to test React or Vue components in isolation with Playwright, or to migrate off @playwright/experimental-ct-react / -vue.
next-partial-prefetching-optimizer
Optimize what selected Next.js client navigations include before the click under Partial Prefetching. Use after Cache Components and Partial Prefetching are adopted when the user wants selected URL-specific UI to be instant, wants reusable content to wait for navigation, or needs to choose between default, viewport…