browser-verification skillA
browser-verification is agent-read markdown (skill) from nahid-sparktales/agent-dispatcher: Prove a UI change actually renders and works — desktop and mobile, controls operated, console clean. Use before reporting any change to rendered UI as done, when asked whether a screen actually functions, or when checking someone else's frontend work. Not for judging whether a design is good, and not a substitute for tests you intend to keep..
Indexed from public GitHub and served as immutable, content-addressed versions. Install it pinned to an exact SHA-256 with the mdr CLI, and every file is verified against the hash recorded here before it reaches your agent. The deterministic audit below grades the latest version, and the same file always earns the same grade.
What the file says
# Browser verification Reading the source is not verification. A component that compiles, type-checks and looks right in the diff can still render blank, overflow its container, or throw on mount. ## When this fires After any change to rendered UI, before that change is reported as working — your own work or someone else's. It does not fire for a change with no rendered surface. One change, checked once, is this skill; a matrix of states across viewports and themes, or a comparison against a screenshot baseline, is `visual-verification`. ## Procedure 1. **Get it running.** Start the dev server or open the deployed URL. If it will not start, that is the finding: report it and stop the verification — never verify a stale build. The work under test is then reported as unverified, not as failed. 2. **Render the route that changed**, not the home page. Wait for network idle before judging. 3. **Read the console and network first**, before looking at pixels. An error here explains most of what you are about to see. Record the exact message, not "some errors". 4. **Inspect desktop.** Screenshot. Does the intended change appear; is anything clipped or …
Read the whole file at its exact version.
How to install
mdr add nahid-sparktales/agent-dispatcher/browser-verification@git:20260919.a0d4f55mdr add nahid-sparktales/agent-dispatcher/browser-verification@sha256:cf4b7c4bdd4ba178Pin to a label to follow the author's releases, or to a sha256 to freeze the exact bytes forever. Either way the resolved hash is written to mdr.lock, and mdr install reproduces it on any machine.
[](https://markdownregistry.com/a/art_26bfoeikgrv6up7m)
1 badge views in 30 days
Versions
Audit of the latest version
- pass: Frontmatter block present
- pass: Frontmatter declares a name
- pass: Frontmatter declares a description
- pass: Size between 200 bytes and 200 KB (3907 bytes)
- pass: No zero-width or bidi control characters
- pass: No instruction hidden inside an HTML comment
- pass: No link to an exfiltration or paste host
- pass: No credential-shaped string
- pass: No instruction to send local credentials anywhere
- pass: No text hidden with inline styles
- pass: No prompt-injection phrasing
- pass: No curl or wget piped into a shell
- pass: No recursive delete of root, home or parent
- pass: No instruction to read or print local credentials
- pass: No base64 blob over 200 characters
- pass: No link to a raw IP address
- pass: No script tag
Source
nahid-sparktales/agent-dispatcher · 49 stars · license MIT · pushed 2026-09-23 · branch main
API
GET https://markdownregistry.com/api/v1/artifacts/art_26bfoeikgrv6up7m GET https://markdownregistry.com/api/v1/resolve?ref=nahid-sparktales/agent-dispatcher/browser-verification GET https://markdownregistry.com/api/v1/blob/cf4b7c4bdd4ba178602363359ac882ddbaee3ed5306ae8ba1d4d047ffab61291
Your agent does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.