Cro Optimization

CRO Optimization

Purpose

Analyze a landing page and deliver a comprehensive CRO audit with specific, actionable recommendations to maximize conversions.

Execution Logic

Check $ARGUMENTS first to determine execution mode:

If $ARGUMENTS is empty or not provided:

Respond with: "cro-optimization loaded, provide your landing page URL or paste your HTML/CSS code"

Then wait for the user to provide their landing page in the next message.

If $ARGUMENTS contains content:

Proceed immediately to Task Execution (skip the "loaded" message).

Task Execution

When landing page is available (either from initial $ARGUMENTS or follow-up message):

1. MANDATORY: Read Reference Files FIRST

BLOCKING REQUIREMENT — DO NOT SKIP THIS STEP

Before doing ANYTHING else, you MUST use the Read tool to read ALL three reference files:

Read: ./references/cro_principles.md
Read: ./references/landing_page_patterns.md
Read: ./references/element_audit_framework.md

What you will find:

• cro_principles.md: 13 core CRO principles with detection criteria and fix patterns
• landing_page_patterns.md: Real patterns from high-converting pages (ClickUp, Notion, Stripe, Apple, etc.) organized by category
• element_audit_framework.md: Systematic framework for auditing HTML elements, CTAs, forms, and visual hierarchy

DO NOT PROCEED to Step 2 until you have read all files and have the principles, patterns, and audit framework loaded in context.

2. Check for Business Context

Check if FOUNDER_CONTEXT.md exists in the project root.

• If it exists: Read it and use the business context to personalize recommendations (industry, target audience, product type, competitors).
• If it doesn't exist: Proceed with analysis based on page content alone.

3. Fetch and Extract Landing Page

If user provided a URL:

• Use WebFetch to retrieve the landing page content
• Extract and catalog key elements (see Element Extraction below)

If user provided HTML/CSS directly:

• Analyze the provided code directly
• Note any missing context (live styling, images, etc.)

4. Element Extraction

Extract and catalog these elements from the page:

Typography:

• H1 (should be exactly one)
• H2s (section headers)
• Body text samples
• CTA button copy

Visual Structure:

• Above-the-fold content
• Section sequence
• Image/visual placement
• Color scheme and contrast

Conversion Elements:

• Primary CTA (copy, placement, design)
• Secondary CTAs
• Forms (field count, labels)
• Trust signals (logos, testimonials, badges)
• Social proof (metrics, reviews, case studies)

Technical:

• Mobile responsiveness indicators
• Load speed concerns (large images, etc.)

5. Audit Against CRO Principles

For each of the 13 principles in cro_principles.md:

1. Check if the page violates the principle
2. Note specific violations with evidence
3. Determine severity (High/Medium/Low)
4. Draft specific recommendations

Prioritize by impact:

• High: Above-fold clarity, CTA effectiveness, major trust gaps
• Medium: Objection handling, visual hierarchy, scannability
• Low: Minor copy tweaks, nice-to-have additions

6. Compare to High-Converting Patterns

Using landing_page_patterns.md:

1. Identify the most relevant category (B2B SaaS, E-commerce, etc.)
2. Compare page structure to proven patterns
3. Note missing elements that top performers include
4. Identify opportunities to adopt successful patterns

7. Generate Recommendations

For each issue found, provide:

1. What to change — specific element and action
2. Why it matters — principle violated and expected impact
3. How to implement — concrete example or rewrite
4. Priority — High/Medium/Low with reasoning

8. Format and Verify

• Structure output according to Output Format section
• Complete Quality Checklist self-verification
• Ensure recommendations are specific and actionable (not generic advice)

Writing Rules

Hard constraints. No interpretation.

Core Rules

• Every recommendation must be specific and actionable
• Include before/after examples for copy changes
• Reference the specific principle violated
• Prioritize by conversion impact, not ease of implementation
• Frame changes as testable hypotheses when possible
• Never recommend changes without explaining the "why"