Product review
Run a UX product review of a Sui dapp (first paint, onboarding, mobile). Use when the user wants a product, UX, or onboarding review.From its SKILL.md
npx -y skills add pivyme/suiperpower --skill product-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
7.4 KB, ~1.8k tokens by cl100k_base, as published. Nobody here has run it
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-movefor code review orottersec-prepfor security.
If you activated this and the user actually wants something else, consult skills/SKILL_ROUTER.md and hand off.
Inputs
.suiperpower/idea-context.mdfor 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
-
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.
-
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.
-
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.
-
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.
- Visit each state deliberately:
-
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.
-
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.
-
Score and prioritize
- Apply the impact / effort matrix from
references/impact-effort-matrix.md. - P0: high impact, low effort. Ship before next demo.
- P1: high impact, medium effort. Within a week.
- P2: medium impact, low effort. When time allows.
- Defer: low impact or high effort with no payoff.
- Apply the impact / effort matrix from
-
Writeback
- Write
.suiperpower/product-review.md. Surface P0 to the user verbally.
- Write
Quality gate (anti-slop)
Before reporting done:
- Did the review actually walk the live product, not just the deck?
- Was the claimed happy path stress-tested with a fresh browser session, no cached state?
- Are findings specific (page, element, observation), not "the UX feels heavy"?
- Is TTFV a measured number, not a guess?
- Does the roadmap rank by impact / effort, not by what the user wants to fix?
- Did the writeback happen?
If any answer is no, the skill keeps working.
References
On-demand references (load when relevant to the user's question):
references/impact-effort-matrix.md: How to assign impact and effort scores per finding.references/ttfv-benchmarks.md: Time-to-first-value targets by product category (DEX, social, indexer, NFT marketplace).
Use in your agent
- Claude Code:
claude "/suiper:product-review <your message>" - Codex:
codex "/product-review <your message>" - Grok Build: run
grok, then/product-review <your message>in the session - Cursor: paste a chat message that includes a phrase like "product review", or load
~/.cursor/rules/product-review.mdcand reference it.
If you activated this and the user actually wants something else, consult skills/SKILL_ROUTER.md and hand off.
What ships with it: 3 files
5.7 KB alongside SKILL.md
agents/
- openai.yaml308 B
references/
- impact-effort-matrix.md2.2 KB
- ttfv-benchmarks.md3.2 KB
Gives 0 of the 12 instructions most review quality skills give in ~1.8k tokens
Counted across 1,048 of the 1,783 authors here whose files we hold, read 2026-08-07
- Ask questions one at a timein 81 of 1048, across 64 files
- Provide a recommended answer for each questionin 73 of 1048, across 50 files
- Explore the codebase instead of asking answerable questionsin 66 of 1048, across 42 files
- Resolve dependencies between decisions one-by-onein 42 of 1048, across 17 files
- Interview the user relentlessly about the planin 38 of 1048, across 13 files
- Order findings by severityin 31 of 1048
- Resolve each branch of the decision treein 27 of 1048, across 5 files
- Run a grilling sessionin 26 of 1048, across 5 files
- Update CONTEXT.md immediately when a term is resolvedin 26 of 1048, across 11 files
- Propose precise canonical terms for vague languagein 25 of 1048, across 7 files
- Create documentation files lazilyin 24 of 1048, across 5 files
- Assign severity to every findingin 24 of 1048
Said here and by no other author read
- Demand a happy path if none is provided
- Open the live URL in a fresh browser session
- Count steps from first paint to first concrete value
- Visit empty error and loading states deliberately
- Test the layout on a mobile viewport
- Measure time from page load to first concrete output
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.