--- name: verify-like-a-visitor description: Use before saying a website or web app "works." Drives the real site in a real browser the way a visitor would, requires proof behind every result, catches the bugs a fresh-page-load test suite misses, and refuses to report a pass it did not observe. --- # Verify like a visitor This is a skill for your AI. It proves a site works instead of assuming it does. A site can pass every automated test and still be broken. Most test suites start each check with a fresh page load, but real visitors do not. They land on one page and click their way through, and bugs hide in exactly that gap. This skill closes it by driving the real site and demanding proof for every result. Use it with any AI system that can open and operate a real browser. The tool can be Playwright, a browser extension, a hosted preview with browser control, a local browser automation tool, or another equivalent setup. The model does not matter. The observation does. ## The gate (do this first, every time) Before anything else, get a real browser you can drive: a browser automation tool such as Playwright or a Chrome extension, a preview URL, or a running dev server you can open and click. If you do not have one, stop here and say so. Do not describe results you did not observe, and do not read the code and call that verification. A made-up passing report is worse than no test, because it hides the failure until a real person finds it. ## The proof rule Every result you report must have a screenshot behind it. After each action, capture the screen and keep it. A check with no screenshot is not a pass and not a fail, it is NOT VERIFIED, and you must label it that way. Unknown is not success. ## The method 1. Inventory. On each page, list every interactive element: links, buttons, form fields, menus, toggles. Screenshot the page. 2. Drive it for real. Use each element. Actually click, type, and submit, and screenshot the result of each action. Watch the browser console for errors: with a tool like Playwright, register a console listener before you start so nothing is missed, and in a plain browser, open the developer tools and check the console after each action. Treat an error as new only if it was not already there before you began. If a page loads its content after a delay, wait for it to settle or give up after about eight seconds, screenshot the final state, and mark it FAIL if it never settles. 3. Move like a visitor. Reach every page by clicking through the site, not by pasting URLs. Walk real journeys end to end, for example: open the home page, click through to a second page, go back, then click somewhere else. This is the step that catches the bugs a fresh load never sees. 4. Push on the edges. Submit a form with an empty required field. Reload in the middle of an action. Click the same button twice quickly. Note what happens each time. 5. Do it again on a phone. Resize the viewport to 375 pixels wide, the common mobile width, and repeat the main journeys. Layouts break and touch targets shrink here in ways that looked fine on desktop. ## Minimum coverage Do not call the run complete until you have tested at least these paths: 1. The homepage loads from a clean start. 2. The main navigation reaches every important page by clicking. 3. The primary call to action works. 4. At least one form, menu, toggle, or other interactive control is pushed past the happy path. 5. The same main journey is repeated at 375 pixels wide. 6. The browser console is checked for new errors. 7. Every PASS has proof behind it, and every missing proof is marked NOT VERIFIED. If the site does not have one of these surfaces, say that clearly in the report. Do not silently skip it. ## What counts as a pass Mark a check PASS only when all four are true: you performed the action, you have the screenshot, what you saw matches what you expected, and the browser console showed no new error. If any one is missing, it is FAIL or NOT VERIFIED, never PASS. ## What to return A table, one row per check, with these columns: element, the action you took, what you expected, what you observed, the console error if any, the screenshot reference, and the result as PASS, FAIL, or NOT VERIFIED. Do not replace the table with a prose summary. Put any FAIL rows at the top and, for each, give the actual cause rather than the symptom, for example "the settings page crashed because the server sent cap_usd but the code read spend_cap," not "the page did not work." ## How to use this with your AI - Claude Code: save this file as `~/.claude/skills/verify-like-a-visitor/SKILL.md` (keep the folder name). It loads on your next session; ask it to "verify like a visitor," and make sure it has a browser tool available. - Cursor: save the body as `.cursor/rules/verify-like-a-visitor.mdc` in your project. - ChatGPT, Gemini, local models, or anything else: paste this whole file into the instructions field, and use it with a browser tool that can actually open the site. ## Hard rule Never mark a check passed that you did not run and cannot show. If you could not drive the site, the honest report is one line: "I could not open and drive this, so nothing here is verified." That line is more useful than a page of results you did not actually see. Written by Rodney John. The build was done by PRISM, the AI build system he made. See the build it came from at rodneybuilds.com.