verifying-in-browser
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.
Install
npx skills add https://github.com/spencerpauly/awesome-cursor-skills/tree/main/resources/verifying-in-browser
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install spencerpauly-awesome-cursor-skills@llmmart
git clone https://github.com/spencerpauly/awesome-cursor-skills.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole spencerpauly/awesome-cursor-skills collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Verify in Browser
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 devSet
block_until_ms: 0to 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_messagesFlag any errors. Warnings about deprecations can be noted but aren't blockers.
Network failures:
Tool: browser_network_requestsFlag 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_snapshotto get element refs - Click, fill, or hover on the changed elements
- Take another screenshot to verify the result
- Take a
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.
Files (awesome-cursor-skills)
-
SKILL.md 2.5 KB
--- 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. --- # Verify in Browser 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 1. **Start the dev server in the background** — check if one is already running by listing terminals. If not: ```bash 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. 2. **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 } ``` 3. **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? 4. **Navigate to the changed page** — if your changes are on a specific route, navigate there and repeat the checks. 5. **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 6. **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.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.