/product-review

name: product-review
description: Run a UX product review of a Sui dapp (first paint, onboarding, mobile). Use when the user wants a product, UX, or onboarding review.

Preamble (run first)

# Suiperpower telemetry. Routes through the CLI so projects.json + Convex stay in sync.
# Silent on failure so the skill never blocks. Opt out: SUIPERPOWER_TELEMETRY=off.
#
# AGENT NOTE: when this skill finishes, run the matching completion command:
#   suiperpower track product-review build completed
# Or use "failed" / "aborted" if it ended that way.
command -v suiperpower >/dev/null 2>&1 && suiperpower track product-review build started >/dev/null 2>&1 &
true

If `TEL_PROMPTED` is `no`, before doing real work, ask the user:

> Help suiperpower get better. We track which skills get used and how long they take. No code, no file paths, no PII. Change anytime in `~/.suiperpower/config.json`. > > A) Sure, anonymous > B) No thanks

Write the answer to `~/.suiperpower/config.json` `telemetryTier` field and create `~/.suiperpower/.telemetry-prompted`. Then continue.

What this skill does

Walks the product as a first-time user would. Catalogues issues across five dimensions: first-paint experience, onboarding friction, empty / error / loading states, mobile experience, and time-to-first-value. Produces a roadmap of UX fixes ranked by impact divided by effort.

Less brutal than `roast-my-product`, more concrete. Where roast is about whether the project survives a hostile reading, product-review is about whether the user gets to the value with as little drag as possible.

When to use it

• Before submitting a hackathon project, alongside or after `roast-my-product`.
• After a build sprint, when the user has shipped enough surface area to have a real walkthrough.
• Before a marketing push, when first-time-user friction will determine conversion.

When NOT to use it

• Pre-MVP, before there are screens to review.
• For internal tools the team uses every day. They will not feel the friction a first-time user feels.
• For pure protocol projects with no app surface. Route to `review-move` for code review or `ottersec-prep` for security.

If you activated this and the user actually wants something else, consult `skills/SKILL_ROUTER.md` and hand off.

Inputs

• `.suiperpower/idea-context.md` for the chosen idea and target user.
• A live URL for the product, or screenshots / a recorded walkthrough.
• The user's claimed "happy path" for a first-time user (the steps they expect a new user to take).
• If a wallet flow exists: the user's intended wallet (Slush, Suiet, Phantom on Sui, etc.) and whether zkLogin is offered.

Outputs

A `.suiperpower/product-review.md` with findings across five dimensions and a prioritized roadmap:

## Product review, <timestamp>

### Inputs reviewed
- live URL: <link or "not provided">
- claimed happy path: <one paragraph>
- target user: <one sentence>

### First-paint experience
- finding 1: <observation>, <impact>
- finding 2: ...

### Onboarding friction
- finding 1: ...
- finding 2: ...

### Empty / error / loading states
- finding 1: ...
- finding 2: ...

### Mobile experience
- finding 1: ...
- finding 2: ...

### Time-to-first-value
- measured TTFV: <seconds, from landing to first concrete value>
- target TTFV: <seconds, based on category>
- finding 1: ...

### Roadmap (prioritized by impact / effort)
- P0 (high impact, low effort): <numbered list, ship before next demo>
- P1 (high impact, medium effort): <numbered list, ship within a week>
- P2 (medium impact, low effort): <numbered list, ship when time allows>
- defer: <findings that are not worth the effort right now>

Workflow

1. **Read context and inputs**

• Pull idea, target user, claimed happy path. If no happy path is provided, demand one.
• Open the live URL in a fresh browser session, no cached state, no logged-in account. If the user has not provided a URL, request screenshots of every page on the path.

2. **First-paint experience**

• What does a first-time user see in the first 5 seconds?
• Is the value clear from the headline alone? Is the CTA visible above the fold? Is the typography load free of font-flash?
• Note any layout shift, missing alt text, hero copy that does not name the user or the outcome.

3. **Onboarding friction**

• From "first paint" to "first concrete value", count the steps.
• For each step, note: is it necessary, is the copy clear, is the input format obvious, are there error fallbacks?
• If the path includes wallet connect, count it as one step. If it includes zkLogin, note the OAuth provider load time.
• Reject "we use industry-standard wallet flow" as defense; the friction is the friction.

4. **Empty / error / loading states**

• Visit each state deliberately:
• Empty: a brand new user with no data. Is the empty state useful or a blank panel?
• Error: cause an error (network off, invalid input, expired session). Does the message explain what to do?
• Loading: throttle the network. Are skeletons shown? Does the UI block, or does it stay responsive?
• Note any state that returns a blank screen, an unstyled error, or an infinite spinner.

5. **Mobile experience**

• Open on a real phone (or 375 px viewport). Does the layout reflow? Are tap targets at least 44 px? Does the wallet connection complete on mobile, including zkLogin redirects?
• Note any horizontal scroll, fixed-positioned elements that block content, or buttons that fail off-screen.

6. **Time-to-first-value**

• Measure: from landing page load to the user receiving the first concrete output (a transaction confirmed, a piece of content rendered, an answer returned).
• Compare to the category benchmark in `references/ttfv-benchmarks.md`.
• If TTFV exceeds the benchmark by 2x, this is a P0 finding regardless of cause.

7. **Score and prioritize**

• Apply the impact / effort matrix from `references/impact-effort-matri