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:

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:

1. Overall UX quality -one paragraph summary
2. Per-page findings -the table from Step 2 for each page visited
3. Flow walkthroughs -what happened in each core flow from Step 3
4. Recurring problems -patterns that appeared across multiple pages
5. 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_snapshot` first to understand page structure. Use browser_take_screenshot for 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.