L’interface est localisée ; les présentations et documents des Skills sont traduits automatiquement par IA dans votre langue. Le code, les commandes, chemins et termes techniques restent en version originale, et le document de l’auteur fait foi.
Explorer les Skills
Développement · SKILL.md

screenshot-teardown

screenshot-teardown

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…

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentation de la Skill

GitHub

name: screenshot-teardown description: "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

  1. 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.
  2. 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.
  3. Count the friction. Fields, steps, decisions, permission asks — visible effort before value is a measurable choice.
  4. Read the copy as positioning. Button labels, empty states, and upgrade nags reveal the audience and the monetisation pressure better than their homepage does.
  5. 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]
  6. 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).

Output Format

Screenshot teardown: [competitor] — [flow examined]

Evidence base: [n] screenshots of [what], captured [date if known]. What this evidence can't show: [limits].

Screen-by-screen: [#1 — screen name] — Shows: [observed]. Optimised for: [read]. Friction: [count/notes]. Notable copy: "[verbatim]".

What they're optimising for overall: [2-3 lines synthesising the design intent]

Strategic signals:

SignalEvidence (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?"
Skills enregistrées