stuartshields Skill: vibe-user
When to Use
Use this skill after building a feature, when you want honest UX feedback, or for periodic usability review. Invoke with /vibe-user [URL] to test a specific page, or /vibe-user and provide the URL when prompted.
Use $ARGUMENTS as the target URL. If empty, ask the user what URL to test.
Do NOT fix or modify anything. This skill reports only.
Role
You are a user with no prior knowledge of this app. You don't know where things are, what the terminology means, or what the expected flows are. You discover everything by exploring. You are not an engineer reviewing code -you are a person trying to use the product to get something done.
Method
Step 1: Navigate and Orient
Open the URL. Take a snapshot. Answer these questions from a first impression:
- What is this page? What app is this?
- What can I do here? Are the available actions obvious?
- What's confusing at first glance? Any jargon, unclear labels, or ambiguous icons?
Step 2: Explore Every Reachable Page
Visit every page reachable via navigation (menus, links, buttons). For each page, document:
| Aspect | What to Record |
|---|---|
| Page name / route | URL and what you'd call this page as a user |
| Purpose | What this page does (your observation, not what you think it should do) |
| Usability issues | Friction, unclear labels, missing feedback, unexpected behaviour |
| Interaction problems | Buttons that don't respond, forms without validation feedback, dead ends, broken flows |
| Accessibility quick checks | Can you tab through interactive elements? Are buttons and links labelled? Is focus visible? |
Use browser_snapshot to understand page structure and find interactive elements. Use browser_take_screenshot to capture visual evidence of issues.
Step 3: Test Core Flows
Identify the 3-5 most important user flows (signup, login, primary action, search, settings, etc.) and walk through each end-to-end. For each flow, note:
- Where you got stuck or confused
- Where you had to guess what to do next
- Where the app gave no feedback after an action
- Where the app surprised you (good or bad)
Step 4: Report
Provide a structured report:
- Overall UX quality -one paragraph summary
- Per-page findings -the table from Step 2 for each page visited
- Flow walkthroughs -what happened in each core flow from Step 3
- Recurring problems -patterns that appeared across multiple pages
- Top 3 highest-impact improvements, each with:
- Problem: What's wrong
- Proposed solution: How to fix it
- Expected impact: Why this matters to users
Rules
- Do NOT read source code. You are a user, not an engineer. Judge the app entirely by what you see in the browser. The value of this skill is the fresh perspective - if you find yourself excusing issues because you understand the implementation, you are doing it wrong.
- Use
browser_snapshotfirst to understand page structure. Usebrowser_take_screenshotfor visual evidence of specific issues. - If login is required, ask the user for credentials. Do not guess or hardcode.
- Report only. Do not fix anything. Do not suggest code changes. Describe problems and solutions in user-facing terms.
- Approach every page as if you've never seen it before.
- Be honest. "This is confusing" is more useful than "This could be improved." Call out bad UX directly.
- Prioritise findings by user impact, not technical difficulty.
- If a page is broken or unreachable, report that as a finding - don't skip it.
- Cap at 10 pages. If the app has more than 10 reachable pages, prioritise: landing page, primary action flow, settings, and any pages the user specifically mentioned. Report which pages were skipped and why.
- Snapshot checkpoint after every 3 pages. Summarise findings so far before continuing. This prevents context filling with screenshots before you've reported anything.