skills/product-appeal-analyzer/SKILL.md
Evaluate product desirability, market positioning, and emotional resonance—the complement to friction analysis. Assess whether users will WANT a product (not just use it), identity fit, trust signals, and value proposition clarity. Activate on "will they like it", "market positioning", "appeal analysis", "product desirability", "value proposition", "why would someone choose this", "landing page review", "conversion optimization", "messaging strategy". NOT for UX friction analysis (use ux-friction-analyzer), visual design implementation (use web-design-expert), or A/B test setup (use frontend-developer).
npx skillsauth add curiositech/windags-skills product-appeal-analyzerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Evaluate whether users will want a product—not just use it. The complement to friction analysis.
Core insight: Users don't choose the best product—they choose the product that feels most like it was made for them.
✅ Use for:
❌ NOT for:
All three must be present. Missing any one kills conversion:
IDENTITY FIT
"This is for people like me"
/\
/ \
/ \
/ ★ \
/ DESIRE \
/ \
/______________\
PROBLEM TRUST
URGENCY SIGNALS
"I need this now" "This will actually work"
| Missing Element | User Reaction | |-----------------|---------------| | Identity Fit | "Seems useful, but not for me" | | Problem Urgency | "Cool, maybe someday" | | Trust Signals | "Looks sketchy / too good to be true" |
Decision tree: When analyzing, score each vertex 1-10. If any is <5, that's your priority fix.
Within 5 seconds of landing, a visitor should know:
How to run it:
Scoring:
| Result | Score | Action | |--------|-------|--------| | All 4 clear in <3 sec | 9-10 | Ship it | | All 4 clear in 3-5 sec | 7-8 | Minor polish | | 3 of 4 clear | 5-6 | Fix the gap | | 2 or fewer clear | 2-4 | Significant rework | | Confusing/unclear | 0-1 | Start over |
For each persona, document:
For each persona:
PERSONA: [Name]
IDENTITY FIT [/10]
Visual identity match [/10] "Does this look like my kind of tool?"
Language resonance [/10] "Do they speak my language?"
Implied user match [/10] "Are people like me shown?"
PROBLEM URGENCY [/10]
Pain point acknowledged [/10] "They understand my problem"
Emotional resonance [/10] "They get how frustrating it is"
Solution clarity [/10] "I see how this fixes it"
TRUST SIGNALS [/10]
Professional execution [/10] "This looks legitimate"
Social proof [/10] "Others like me use it"
Risk reduction [/10] "What if it doesn't work?"
OVERALL APPEAL SCORE: [/90]
| Objection | Type | How Addressed? | |-----------|------|----------------| | "Is this legit?" | Trust | [Answer] | | "I've tried things before" | Skepticism | [Answer] | | "Too expensive" | Value | [Answer] | | "Too complicated" | Effort | [Answer] | | "Not for people like me" | Identity | [Answer] | | "What if it doesn't work?" | Risk | [Answer] | | "I'll do it later" | Urgency | [Answer] |
Use priority formula: Impact = (Users Affected × Severity) / Fix Difficulty
Categorize into:
Novice thinking: "List all capabilities to show value"
Reality: Visitors scan for 2-3 seconds. Feature lists feel generic.
What to use instead: | Bad | Good | |-----|------| | "AI-Powered Recovery Planning Tool with Analytics" | "Know exactly what to do next in your recovery" | | "Comprehensive Legal Document Platform" | "Find out in 2 minutes if your record can be expunged" |
Detection: Headline contains 3+ nouns or buzzwords like "AI-powered", "comprehensive", "platform"
Novice thinking: "Show the product interface so people know what they're getting"
Reality: Strangers don't understand your UI. They care about outcomes.
What to use instead:
Detection: Hero image is a product screenshot with no context
Novice thinking: "Get their email immediately, then convert them"
Reality: Trust builds in stages. Asking for too much too early kills conversion.
The Trust Ladder (each rung requires more trust):
Detection: Asking for account creation before demonstrating value
Novice thinking: "Broad appeal = more users"
Reality: When everyone is the target, no one feels targeted.
What to use instead: | Signal Type | How It Works | |-------------|--------------| | Visual identity | Dark mode = "power user"; Soft pastels = "wellness" | | Language/tone | "Crush your goals" vs "Find your balance" | | Social proof | Company logos vs individual testimonials | | Complexity | Minimal = simplicity-seeker; Feature-rich = power user |
Detection: Homepage tries to appeal to 3+ different personas
Run: python scripts/appeal_scorer.py <url>
Produces structured JSON output with scores and recommendations.
| File | When to Use |
|------|-------------|
| references/scoring-templates.md | Full scoring matrices and templates |
| references/trust-ladder.md | Deep dive on trust building stages |
| references/identity-signals.md | Visual/verbal identity signal catalog |
| references/objection-catalog.md | Common objections by product type |
When running this skill, produce:
Appeal + Friction = Complete picture
| This Skill Answers | ux-friction-analyzer Answers | |--------------------|------------------------------| | "Do they want it?" | "Can they use it?" | | Will they choose this over alternatives? | Can they complete the task? | | Does it feel made for them? | Does the flow make sense? | | Is the promise compelling? | Is the experience smooth? |
Run both: High appeal + high friction = frustrated users. Low friction + low appeal = abandoned product.
Philosophy: A product with low friction but low appeal gets abandoned. A product with high appeal but high friction gets frustrated users. You need both.
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.