go
Opens the running app in a browser and verifies recent UI changes actually work. Use whenever the user wants a quick smoke test or sanity check of recent work, or says "go", "open in browser", "check in browser", "test your work", "make sure it works", "smoke test", "verify", "did it actually work", "make sure the form/page works", "check the form submits", "works on mobile" — even when they don't explicitly ask for browser testing. Also activates implicitly when the user appends "...and make sure it works" to a UI request. Skips design critique; for that, use go-ui.
Works with
--- name: go description: Opens the running app in a browser and verifies recent UI changes actually work. Use whenever the user wants a quick smoke test or sanity check of recent work, or says "go", "open in browser", "check in browser", "test your work", "make sure it works", "smoke test", "verify", "did it actually work", "make sure the form/page works", "check the form submits", "works on mobile" — even when they don't explicitly ask for browser testing. Also activates implicitly when the user appends "...and make sure it works" to a UI request. Skips design critique; for that, use go-ui. license: MIT --- # /go — Browser check Verify your work in the browser instead of trusting that code compiles. Use whatever browser tools the environment offers (Chrome extension, next-devtools MCP, chrome-devtools MCP, Playwright — whichever is reachable). If `chrome-devtools` MCP is available and you need console errors, network status, or computed styles to confirm the fix, prefer it over a blind reload. If login is needed, credentials usually live in `.env.local` or the project's secrets manager. Two things are easy to miss: - **Functional verification** — did the page actually return what was expected? Searching for "X" should show results containing X, not just render without errors. - **Console and network** — JS errors and 4xx/5xx are silent killers. If something is broken, fix → reload → verify again. Don't thrash on the same issue — ask for direction instead.
More Testing skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
setup-pre-commit
mattpocock/skills
Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.
agent-browser
vercel-labs/agent-browser
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.

