Skip to main content
ClaudeWave
Skill2.1k repo starsupdated 7d ago

conversion-optimization

Guided journey from a leaking conversion flow - landing page, signup, checkout, or in-app onboarding - to a measured, tested funnel. Orchestrates six skills phase by phase - lean-analytics, cro-methodology, storybrand-messaging, hundred-million-offers, influence-psychology, design-everyday-things - each phase carries its full method inline so it runs standalone, asking the user questions at every decision point and recording results in the project docs/ folder (FUNNEL.md, METRICS.md, EXPERIMENTS.md, CONVERSION-OPTIMIZATION-PLAN.md) so the journey resumes across sessions. Use when the user wants to raise conversion on a specific flow, fix checkout or signup abandonment, diagnose onboarding drop-off, or says ''people start but never finish''. With no site yet, use create-website; for a whole-site look, message, and speed audit, improve-website; if the flow converts but needs traffic, grow-website; for in-product engagement and retention, improve-app. For one framework in isolation, invoke that skill directly.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/wondelai/skills /tmp/conversion-optimization && cp -r /tmp/conversion-optimization/plugins/metaskills/skills/conversion-optimization ~/.claude/skills/conversion-optimization
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# Conversion Optimization

Turn one leaking conversion flow — a landing page, a signup, a checkout, an in-app onboarding — into a
measured, tested funnel. This is an interactive, resumable journey of seven phases: the agent asks
before every decision and records the outcome in your project's `docs/` folder, so you can stop after
any phase and pick up later. It works on websites and inside products alike; the unit of work is the
flow and its ONE action, not the whole site.

## Core Principle

**Find the leak with numbers, learn the reason from customers, fix message → offer → proof → friction
in that order, and prove every fix with a pre-committed test.** The order is causal: a number tells
you *where*, only research tells you *why*, motivation must be raised before friction-cutting pays,
and an untested fix is a guess that compounds. This skill sequences the phases, asks the decision
questions, and records every choice in `docs/`. The constituent skills carry the method — invoke them
rather than improvising their frameworks.

## Journey Map

| Phase | Skill | Question it answers | Artifact |
|---|---|---|---|
| 1 | lean-analytics | Where does the flow actually leak, and what is the one metric? | Extends docs/METRICS.md — GATE |
| 2 | cro-methodology | Why do people drop at the leak — which objections and friction? | Creates docs/FUNNEL.md; extends docs/EXPERIMENTS.md — GATE |
| 3 | storybrand-messaging | Does the leaking step promise the visitor's own desired outcome in five seconds? | Extends docs/POSITIONING.md + docs/FUNNEL.md + docs/EXPERIMENTS.md |
| 4 | hundred-million-offers | Is the offer at the conversion point worth acting on now? | Extends docs/OFFER.md + docs/EXPERIMENTS.md |
| 5 | influence-psychology | Is there honest proof at every point of doubt? | Extends docs/FUNNEL.md + docs/EXPERIMENTS.md |
| 6 | design-everyday-things | Can a visitor who decided to act complete the flow without stumbling? | Extends docs/FUNNEL.md + docs/DESIGN.md + docs/EXPERIMENTS.md |
| 7 | cro-methodology | Will we know the fix worked — pre-committed metric, sample size, no peeking? | Extends docs/EXPERIMENTS.md + docs/METRICS.md |

## Operating Rules

1. **Resume first.** Before anything else, read `docs/CONVERSION-OPTIMIZATION-PLAN.md` and every artifact in the Journey Map. If the tracker exists, summarize the journey state in 3-5 lines and ask which phase to enter. Done when the user has confirmed an entry point. A journey with a tracker is resumed, never restarted.
2. **Intake on first run only.** No tracker: run the Intake below, then create `docs/CONVERSION-OPTIMIZATION-PLAN.md` with every phase statused `pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason`. Done when the tracker exists and the user has confirmed the phase plan.
3. **Phase entry.** Announce: what the phase does, the decision it forces, the artifact it produces, rough effort. Offer proceed / skip / defer — phases marked GATE may be deferred, never skipped. Mark the phase `in-progress` on proceed. Done when the user chose.
4. **Skill invocation and fallback.** Load the phase's skill and use it: each phase's Invoke line names the skill by slug — use that skill to run the phase. If it is not available, offer: `npx skills add wondelai/skills/<slug> --global`. If the user declines, run the phase from its Brief — the minimum viable method. State which mode you are in.
5. **In-phase decisions.** Ask every question under "Decide with the user" — with concrete options and your recommendation. Record the choice in the tracker's Key Decisions. A decision made silently is a defect.
6. **Phase exit.** Present the draft artifact content for sign-off before writing. On approval: write or extend the docs/ files, update the tracker (status, Key Decisions, Next Actions). Done when the files are written and the phase row shows `done`.
7. **Artifact discipline.** Read before writing; create a file only if missing, otherwise extend — add or update your sections, preserve everyone else's. Files are UPPERCASE in `docs/`. Every recommendation lands as a checkbox or a table row with owner and priority. See [references/artifact-templates.md](references/artifact-templates.md) when creating a docs/ file for the first time — create it from the full skeleton (all section headings), then fill the sections your phase names.
8. **Measure, research, then change — and every change is a test.** No fix ships without a Phase 1 leak and a Phase 2 researched reason behind it, and every shipped change lands in docs/EXPERIMENTS.md with a pre-committed primary metric and a guardrail. A fix with no research behind it goes back to Phase 2; a bold change with no test attached stays in the backlog until it has one.

## Intake

Ask these before creating the tracker:

1. **Which flow are we optimizing, and what is the ONE action at its end?** (Scopes every phase — a flow with three competing CTAs has no goal.)
2. **Where do the numbers say people drop** — analytics, funnel steps, cohort data? Paste what you have. (Feeds the Phase 1 leak diagnosis; no instrumentation means Phase 1 starts by adding it.)
3. **Roughly how much traffic or volume enters the flow per week?** (Gates Phase 7 — decides whether A/B tests can reach significance or the journey leans on qualitative evidence and before/after windows.)
4. **What voice-of-customer sources exist or can be gotten** — exit surveys, session recordings, support tickets, sales calls, reviews — and can you paste or export the raw text of the best one? (Phase 2 objections must quote the customer's own words, so the phase needs the content, not just the source name.)
5. **What is the current offer at the conversion point** — price, guarantee, bonuses — and can it change? (Gates Phase 4; a contractually fixed offer narrows it to presentation.)
6. **Do docs/POSITIONING.md or docs/OFFER.md already exist from another journey?** (Phases 3-4 build on them rather than restarting.)
7. **How much of the jou
37signals-waySkill

Build 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.

blue-ocean-strategySkill

Create 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.

clean-architectureSkill

Structure 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.

clean-codeSkill

Write readable, maintainable code through disciplined naming, small functions, and clean error handling. Use when the user mentions "clean up this code", "this function is too long", "code smells", "naming conventions", "boy scout rule", "single responsibility", or "unit test quality". Also trigger when reviewing a pull request for readability, untangling a messy function, debating comment styles, or improving error-handling patterns. Covers SRP, comment discipline, formatting, and unit testing. For refactoring techniques, see refactoring-patterns. For architecture and dependency rules, see clean-architecture.

contagiousSkill

Engineer word-of-mouth and virality using the STEPPS framework (Social Currency, Triggers, Emotion, Public, Practical Value, Stories). Use when the user mentions "go viral", "word of mouth", "shareable content", "social currency", "why people share", "referral program", "nobody is sharing it", or "make this spread". Also trigger when designing shareable features, crafting social campaigns, or building products that spread through peer recommendation. Covers environmental triggers and high-arousal emotional content. For sticky messaging, see made-to-stick. For persuasion tactics, see influence-psychology.

continuous-discoverySkill

Build a weekly cadence of customer touchpoints using Opportunity Solution Trees, assumption mapping, and interview snapshots. Use when the user mentions "continuous discovery", "opportunity solution tree", "weekly interviews", "assumption testing", "discovery habits", "product trio", "outcome-based roadmap", "how do I talk to customers regularly", "we keep building things nobody uses", or "connect research to the roadmap". Also trigger when setting up regular customer feedback loops, prioritizing which experiments to run, or tying discovery insights to delivery work. Covers experience mapping, co-creation, and prioritizing opportunities. For interview technique, see mom-test. For team structure, see inspired-product.

cro-methodologySkill

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.

crossing-the-chasmSkill

Navigate the technology adoption lifecycle from early adopters to mainstream market. Use when the user mentions "crossing the chasm", "beachhead segment", "whole product", "early adopters vs mainstream", "tech go-to-market", "bowling pin strategy", "technology adoption lifecycle", "pragmatist buyers", "growth stalled after early adopters", or "our go-to-market plan". Also trigger when planning go-to-market for a technical product. Covers the D-Day analogy, bowling-pin strategy, the tornado, and positioning against incumbents. For product positioning, see obviously-awesome. For new market creation, see blue-ocean-strategy.