Mmcp.market

cro-methodology skill

by wondelai·wondelai/skills·2.3k stars·MIT

Audit websites and landing pages for conversion issues and design evidence-based A/B tests. Use when the user mentions "landing page isnt converting", "conversion rate", "A/B test", "why visitors leave", "objection handling", "bounce rate", "conversion funnel", "increase signups", or "people add to cart but dont buy". Also trigger when diagnosing why signups are low, designing experiment hypotheses, or auditing checkout flows for friction points. Covers funnel mapping, persuasion assets, and objection/counter-objection frameworks. For overall marketing strategy, see one-page-marketing. For usability issues, see ux-heuristics.

A100/100content scan

Is the cro-methodology skill safe?

Clean: nothing in its files matched our rules. We read 7 files in the folder on 2026-09-28.

No findings.

Install the cro-methodology skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description. 

git clone --depth 1 https://github.com/wondelai/skills.git /tmp/skills
mkdir -p ~/.claude/skills
cp -r /tmp/skills/plugins/wondelai-skills/skills/cro-methodology ~/.claude/skills/cro-methodology
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

CRO Methodology

Scientific, customer-centric approach to conversion rate optimization based on the CRE Methodology(TM). Extraordinary improvements come from understanding WHY visitors don't convert, not from copying competitors or applying generic tips.

Core Principle

Don't guess -- discover. Every visitor who doesn't convert has a reason. Discover those reasons through research, then systematically eliminate them with evidence and proof. This evidence-based approach consistently outperforms "best practices", intuition, competitor copying, and expert opinion.

Scoring

Goal: 10/10. Score any landing page, funnel, or conversion flow against the seven Quick Diagnostic rows below: award ~1.4 points per row answered "yes" (7 rows = 9.8, capped at 10). Bands: 9-10 = single clear action, research-grounded O/CO table, value prop legible in 5 seconds, proof at every friction point, funnel mapped, path free of UX blockers; 5-6 = guessed objections, generic best-practices copy, proof buried in FAQs; <=3 = competing CTAs, no funnel map, claims with no proof. Report the current score and the specific diagnostic rows failing.

The CRO Frameworks

1. The CRO Process

Core concept: A systematic 9-step process moving from defining success metrics through research and experimentation to scaling wins across the business.

Why it works: Random optimization skips research. The process forces you to understand visitors before changing anything, so every change rests on evidence, not opinion.

Key insights:

  • Define success metrics aligned with business KPIs before touching any page
  • Map the entire funnel to find "blocked arteries" (high-traffic underperforming paths) and "missing links" (absent funnel stages)
  • Research visitors in three dimensions: who they are, what blocks them (UX problems), what stops them (objections)
  • Gather market intelligence from competitors, reviews, and other industries
  • Prioritize ideas with ICE scoring; design bold experiments, not "meek tweaks"
  • Run experiments with statistical rigor (95% confidence minimum, full business cycles), then scale wins across the business

Product applications:

Copy patterns:

  • "What's preventing you from [action] today?" (exit survey to discover objections)
  • "Here's what [X] customers found..." (counter-objection with social proof)

See funnel-analysis.md when mapping the funnel -- step-by-step mapping, blocked-artery/missing-link diagnosis, industry funnel benchmarks, and impact-based prioritization.

2. Customer Research & Objections

Core concept: Visitors fail to convert for specific, discoverable reasons. Exit surveys, chat logs, support tickets, sales calls, and reviews reveal the "voice of the customer" and their real objections.

Why it works: Teams' guesses about why visitors leave are almost always wrong. Research uncovers objections no one anticipated, and the customer's own language out-persuades any copywriter's invention.

Key insights:

  • Primary sources (exit surveys, live chat, tickets, sales calls) give direct visitor language; secondary sources (reviews, social media, competitors) reveal industry-wide objections
  • The "Big 5" universal objections: Trust, Price, Fit, Timing, Effort
  • Quantitative research (analytics, heatmaps) shows WHERE problems are; qualitative (surveys, interviews) shows WHY
  • Non-converter surveys should ask ONE question for maximum response; post-purchase surveys ("What almost stopped you from buying?") reveal the objections that matter most

Product applications:

Copy patterns:

  • Use exact customer language in headlines and body copy -- it outperforms polished marketing copy
  • "What's the one thing we could change to make you [action]?"
  • "How would you describe [product] to a friend?" (reveals positioning in customer terms)

Ethical boundary: Anonymize data, get consent for recordings, and don't survey so aggressively that you degrade the experience.

See RESEARCH.md when planning research -- ready-to-use survey questions per channel, recommended tools, and how to turn raw responses into a ranked objection list.

3. Persuasion Assets

Core concept: Every company sits on overlooked proof -- undisplayed testimonials, unmentioned awards, hidden credentials, buried guarantees. Inventory these "persuasion assets", acquire missing ones, display them.

Why it works: Visitors decide on evidence, not claims. A modest claim with overwhelming proof beats a bold claim with none.

Key insights:

  • Audit five categories: Credentials & Authority, Social Proof, Risk Reversal, Data & Specificity, Process & Methodology
  • Create a wish list for missing assets and actively acquire them (request testimonials, apply for awards, compile statistics)
  • "Proof sandwich" structure: Claim (bold promise), then Proof (evidence), then Reinforcement (secondary proof)
  • Proof hierarchy, strongest first: specific results with context > named testimonials with photos > case studies > statistics > logos > generic testimonials
  • Place proof at points of friction, not in FAQs; specific numbers beat round ones ("47,832 customers" beats "About 50,000")

Product applications:

Copy patterns:

  • "Here's how we did it for [Company X]..." (case study proof)
  • "[Specific number] businesses trust us" (not "thousands of customers")
  • Lead with benefits, not features: "Never delete another photo" beats "256GB storage"

Ethical boundary: Never fabricate testimonials, inflate statistics, or display fake trust badges -- all proof must be genuine and verifiable.

See PERSUASION.md when auditing or acquiring proof -- the full five-category asset checklist and psychological triggers. See COPYWRITING.md when writing the proof copy itself -- headline formulas, benefit-led phrasing, and proof-element wording.

4. The O/CO Framework

Core concept: The Objection/Counter-Objection table is the core CRE technique: map every visitor objection to a specific, evidence-backed counter-objection.

Why it works: The table forces every counter to be placed where its objection arises in the reading flow, so a concern is answered the instant the visitor feels it -- not pages later, by which point they have already left.

Key insights:

  • Research objections from surveys, chat logs, tickets, and sales calls -- don't guess
  • Implicit objections (ones visitors won't admit) require "CO Only": counter without stating the objection
  • Place counter-objections at the point of friction (credit-card objection near the payment form), not buried in FAQ
  • Address primary objections above the fold; repeat the same counter in multiple formats (text, video, testimonial, data)
  • Canned support responses are goldmines of tested counter-objections

Product applications:

Copy patterns:

  • Bad (states implicit objection): "Worried you're too lazy to learn a language?"
  • Good (CO Only): "Let the audio do the work for you."
  • "What almost stopped you from buying?" (post-purchase survey to validate the O/CO table)

Ethical boundary: A counter-objection must resolve the concern with real evidence, not dismiss a legitimate worry as unfounded.

See OBJECTIONS.md when building the O/CO table -- per-category counter-objection technique catalogs, CO-Only patterns for implicit objections, and how to mine objections from support logs.

5. Hypothesis Design

Core concept: Every experiment needs a documented hypothesis linking a specific change to an expected outcome for a research-grounded reason, prioritized with ICE scoring (Impact, Confidence, Ease).

Why it works: A hypothesis forces you to articulate WHY a change should work, grounding it in customer research. ICE scoring stops teams wasting traffic on low-impact tweaks.

Key insights:

  • Format: "If we [change X], then [metric Y] will improve because [reason based on research]"
  • Define primary (decides winner), secondary (monitoring), and guardrail (must not decrease) metrics before testing
  • ICE, 1-10 each: Impact (could this double conversion?), Confidence (how strong is the research?), Ease (how easy to implement?); prioritize by the average
  • The 10x screen: if a change couldn't 10x results, deprioritize it. Worth testing: complete redesign, new value proposition, fundamentally different offer. Not worth testing: button color, font size, image swap

Worked example: "Customer language from surveys will lift signups because visitors see their own words" scores I:8, C:9, E:10 = 9.0 -- a top-priority test. A button-color swap scores ~I:2, C:2, E:10 = 4.7 and gets skipped despite being trivial to build.

Copy patterns:

  • "Based on our research, visitors' #1 objection is [X]. This test addresses it by [Y]."
  • Document before: hypothesis, primary metric, sample size, duration. Document after: raw numbers, confidence interval, learnings, next steps

See testing-methodology.md when prioritizing or scoring a backlog -- per-axis ICE scoring rubrics, a worked prioritization table, and the weighted-ICE variant.

6. A/B Testing Methodology

Core concept: Run controlled experiments comparing page versions with proper statistical rigor, so results reflect reality rather than random noise.

Why it works: Without rigor you can't distinguish real improvements from random variation -- peeking, undersized samples, and ignored practical significance all manufacture false winners.

Key insights:

  • Calculate required sample size BEFORE starting (baseline rate, minimum detectable effect, 80% power, 95% significance)
  • Run at least one full business cycle (1-2 weeks), covering weekdays AND weekends
  • Never peek at results and stop early -- it dramatically inflates false positives
  • Practical significance matters: a statistically significant 0.1% lift isn't worth implementation complexity
  • Use multivariate only with 100k+ monthly visitors on a proven winning page
  • Promote winners to the new control; a failed test that teaches you something beats a win you don't understand

More skills from wondelai/skills

  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • A37signals-wayBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Aarchitecture-optimizationGuided journey from a working codebase grown slow and tangled to one measurably fast, cleanly bounded, and readable. Orchestrates eight skills phase by phase - working-with-legacy-code, clean-architecture, software-design-philosophy, refactoring-patterns, system-design, ddia-systems, release-it, pragmatic-programmer - every phase carries its method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (PERFORMANCE.md, ARCHITECTURE.md, ARCHITECTURE-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to make an app faster, untangle drifted boundaries, fix slow endpoints and queries, or says ''it works but it is slow and getting worse''. For an untested prototype, improve-code-quality; for an aged codebase you fear to touch, remove-technical-debt; for greenfield structure, design-code-architecture; for marketing-site page speed, improve-website. For one framework in isolation, invoke that skill directly.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Ablue-ocean-strategyCreate uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
  • Aclean-architectureStructure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.

All agent skills → · MCP servers