Browser Verify

Verifies UI changes in a real browser before declaring them done — drive the changed flow, check the console, test the mobile viewport, and report what was actually seen. Use whenever a change touches anything a user sees or clicks, and before any "fixed" or "done" claim about frontend work.

Run it as a prompt

Paste this into any AI agent, or fetch it: curl -s https://uplift.page/api/v1/prompts/browser-verify/raw

prompt.md

# Browser Verify

A UI change that compiles is not a UI change that works. "Done" for frontend work means
the changed flow was driven in a real browser and watched doing the right thing — not
that the build passed and the code looks correct.

## When to use

- Any change to pages, components, styles, forms, navigation, or client state
- Before writing "fixed", "done", or "should work now" about anything user-visible
- Reviewing frontend work that arrives with no evidence it was opened

## Steps

1. **Open the app** with whatever browser automation or preview the environment
   provides; start the dev server if none is running. Behind a login wall, follow the
   verify-authed-apps skill instead of skipping.
2. **Drive the changed flow specifically** — click the button, submit the form, follow
   the navigation. Rendering the page is not exercising the change.
3. **Watch the console and network** while driving: new errors, warnings, failed
   requests, and hydration mismatches are failures even when the pixels look right.
4. **Check the mobile viewport** (~375px) for layout, nav, and forms the change
   touches; then the state extremes the change can produce — empty, loading, error,
   long content.
5. **Capture evidence**: a screenshot of the working flow, or the exact text observed.
   Report what was verified and on which viewport, not "it works".

## Rules

1. No user-visible change ships on build output alone — the browser check is the
   definition of done.
2. Verify the failure path too: force the error branch once (bad input, failed
   request) and confirm the UI degrades as designed.
3. When browser access is genuinely unavailable, say so explicitly, name what was
   verified instead, and mark the browser check as still owed — never silently
   downgrade "verified" to "compiled".
4. Console noise that predates the change isn't yours to fix silently — note it,
   don't ignore it.

## Examples

```text
Good: "Drove signup -> verify -> dashboard at 1440px and 375px; console clean; error
       branch (duplicate email) renders the inline message. Screenshot attached."
Bad:  "Build passes and the logic is straightforward, so the flow should work."
```

Install it as a skill

Agents that support the Agent Skills standard load it automatically when it applies.

download

curl -fsSL https://uplift.page/p/browser-verify/SKILL.md --create-dirs -o .agents/skills/browser-verify/SKILL.md

or from any MCP client

MCP server: https://uplift.page/mcp
Tool: pull_skill  {"slug": "browser-verify"}

The full skill

A UI change that compiles is not a UI change that works. "Done" for frontend work means the changed flow was driven in a real browser and watched doing the right thing — not that the build passed and the code looks correct.

When to use

Any change to pages, components, styles, forms, navigation, or client state
Before writing "fixed", "done", or "should work now" about anything user-visible
Reviewing frontend work that arrives with no evidence it was opened

Steps

Open the app with whatever browser automation or preview the environment provides; start the dev server if none is running. Behind a login wall, follow the verify-authed-apps skill instead of skipping.
Drive the changed flow specifically — click the button, submit the form, follow the navigation. Rendering the page is not exercising the change.
Watch the console and network while driving: new errors, warnings, failed requests, and hydration mismatches are failures even when the pixels look right.
Check the mobile viewport (~375px) for layout, nav, and forms the change touches; then the state extremes the change can produce — empty, loading, error, long content.
Capture evidence: a screenshot of the working flow, or the exact text observed. Report what was verified and on which viewport, not "it works".

Rules

No user-visible change ships on build output alone — the browser check is the definition of done.
Verify the failure path too: force the error branch once (bad input, failed request) and confirm the UI degrades as designed.
When browser access is genuinely unavailable, say so explicitly, name what was verified instead, and mark the browser check as still owed — never silently downgrade "verified" to "compiled".
Console noise that predates the change isn't yours to fix silently — note it, don't ignore it.

Examples

Good: "Drove signup -> verify -> dashboard at 1440px and 375px; console clean; error
       branch (duplicate email) renders the inline message. Screenshot attached."
Bad:  "Build passes and the logic is straightforward, so the flow should work."

Served from the uplift.page library and refreshed within 5 minutes of every update.