| name | verifying-in-browser |
| description | After making code changes, start the dev server, open the app in Cursor's built-in browser, and verify everything works — check rendering, console errors, and network health. Use proactively after any UI or API change. |
On-demand loading: Read this skill only when the task clearly matches the description above or trigger phrases below. Do not load for unrelated work.
Verify in Browser
Routing: This skill is for post-change verification of your own edits (dev server, health check, changed routes). For a broader exploratory QA sweep, use visual-qa-testing.
Use this skill proactively after making code changes to verify the app actually works. Don't just trust that the code is correct — launch it and check.
Steps
-
Start the dev server in the background — check if one is already running by listing terminals. If not:
npm run dev
Set block_until_ms: 0 to run it in the background. Then poll until you see the "ready" message with the localhost URL.
-
Open in the side browser — launch the app beside your code:
Tool: browser_navigate
Arguments: { "url": "http://localhost:3000", "position": "side", "take_screenshot_afterwards": true }
-
Quick health check — run these three checks:
Console errors:
Tool: browser_console_messages
Flag any errors. Warnings about deprecations can be noted but aren't blockers.
Network failures:
Tool: browser_network_requests
Flag any 4xx/5xx responses, failed fetches, or CORS errors.
Visual check:
Review the screenshot. Does the page render? Is the layout correct? Are there any blank screens or loading spinners that never resolve?
-
Navigate to the changed page — if your changes are on a specific route, navigate there and repeat the checks.
-
Test interactions — if you changed a form, button, or interactive element:
- Take a
browser_snapshot to get element refs
- Click, fill, or hover on the changed elements
- Take another screenshot to verify the result
- Report the verdict — tell the user:
- "Verified in browser — page renders correctly, no console errors, all network requests healthy."
- Or: "Found issues: [list of problems]"
When to Use This
- After changing any React component, CSS, or layout code
- After modifying API routes or data fetching
- After updating environment variables or configuration
- After installing or removing dependencies
- Before committing — as a final sanity check
Notes
- Use
position: "side" to see code and browser at the same time.
- If the dev server is already running, skip step 1 and go straight to navigating.
- For SSR apps, check both the initial server-rendered HTML and the client-hydrated state.