Tear down a competitor's product from screenshots of its actual UI — onboarding, pricing page, core flows. Use when given screenshots of a rival's app or website and asked what they're doing, how their flow works, or what to learn/steal/avoid. Produces a UX-and-strategy teardown grounded in what is visibly on screen, with an inferences-vs-observations split. Requires image input. For a market-level teardown without screenshots use competitor-teardown.
Start a fresh conversation. Replace the highlighted placeholders.
Use screenshot-teardown to analyze [competitor screenshots] for [our product and decision], producing screen-by-screen observations, clearly labelled inferences, friction counts, limits, and learn/steal/avoid recommendations.
Required inputs
[competitor screenshots]
[our product and decision]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
SKILL.md
name: screenshot-teardowndescription: "Tear down a competitor's product from screenshots of its actual UI — onboarding, pricing page, core flows. Use when given screenshots of a rival's app or website and asked what they're doing, how their flow works, or what to learn/steal/avoid. Produces a UX-and-strategy teardown grounded in what is visibly on screen, with an inferences-vs-observations split. Requires image input. For a market-level teardown without screenshots use competitor-teardown."
Screenshot Teardown Skill
Marketing pages say what a competitor claims; screenshots show what they shipped. This skill reads real UI evidence — layout, copy, defaults, friction, what's promoted and what's buried — and turns it into competitive insight you can defend, because every claim points at pixels.
What This Skill Produces
A screen-by-screen read: what each screenshot shows, what the design is optimising for, where the friction is
Strategic inferences — pricing/packaging signals, target-user signals, maturity signals — each labelled as inference and tied to its visual evidence
Learn / steal / avoid recommendations for your own product
Required Inputs
The screenshots (up to ~5 per pass; more → ask which flow matters most). If none attached, ask — never tear down from memory of the product.
Your product and angle (ask if missing): who's analysing, and for what decision (pricing? onboarding redesign? battlecard?)
Reading Method
Anchor every claim to pixels. "Their onboarding asks for a credit card at step 1" — only if the screenshot shows it. Cite which screenshot each observation comes from.
Read the hierarchy, not just the content. What's biggest, first, pre-selected, and colourful is what they want used; what's behind a "More" menu is what they don't. Defaults are strategy.
Count the friction. Fields, steps, decisions, permission asks — visible effort before value is a measurable choice.
Read the copy as positioning. Button labels, empty states, and upgrade nags reveal the audience and the monetisation pressure better than their homepage does.
Separate the two registers strictly:
Observed — on screen, citable
Inferred — a reading of intent ("the pre-selected annual plan suggests LTV pressure"), always labelled [inference]
Mind the screenshot's limits. One user's session, one plan tier, one moment. Note what state the shots can't show (A/B variants, other tiers, mobile vs desktop).
What they're optimising for overall: [2-3 lines synthesising the design intent]
Strategic signals:
Signal
Evidence (screenshot #)
Observed / Inference
For us — learn / steal / avoid:
Learn: [pattern worth understanding]
Steal: [specific, adaptable pattern — with what to change]
Avoid: [their visible mistake and why we think it's one]
Quality Checks
Every observation cites its screenshot; every inference is labelled [inference]
Copy is quoted verbatim where it carries the point, not paraphrased
The friction count is actual (fields/steps visible), not vibes
The teardown states what the screenshots cannot show
Recommendations name what to change when stealing a pattern — context transplants fail
Anti-Patterns
Do not analyse a product from training-data memory when screenshots are provided — the pixels are the source of truth, and the product has probably changed
Do not proceed without images — that's competitor-teardown's job
Do not present inferences as facts — "they're struggling with churn" is a reading, not a screenshot
Do not sneer — "cluttered" is not analysis; name what the clutter costs and whom it serves
Do not extrapolate a whole strategy from one screen — say when the evidence is thin
Example Trigger Phrases
"Tear down this competitor's onboarding from these screenshots."
"How does their flow work?"
"What should we learn, steal or avoid from their pricing page?"
"Here are screenshots of their app: what are they doing?"
screenshot-teardown by mohitagw15856 · The Skill Leaderboard