Mmcp.market

improve-retention skill

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

Diagnose and fix retention problems using behavior design (B=MAP). Use when the user mentions "users sign up but dont stick around", "activation rate", "onboarding friction", "retention metrics", "why users dont complete", "churn analysis", or "aha moment". Also trigger when analyzing cohort retention curves, designing activation milestones, reducing time-to-value for new users, or investigating why users quit after their first session. Covers the Ability Chain, prompt design, and tiny behaviors that compound. For habit loops and variable rewards, see hooked-ux. For intrinsic motivation, see drive-motivation.

A100/100content scan

Is the improve-retention skill safe?

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

No findings.

Install the improve-retention 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/improve-retention ~/.claude/skills/improve-retention
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

Behavior Design Framework

Framework for designing products that reliably change behavior. Behavior is not about willpower or motivation — it is a design problem with a predictable equation.

Core Principle

The Fogg Behavior Model = B=MAP. Behavior happens when Motivation, Ability, and a Prompt converge at the same moment.

HIGH ┃
                 ┃   ★ Behavior happens
                 ┃  (above the Action Line)
                 ┃
  Motivation     ┃━━━━━━━━━━━━━━━━━━━━━━━ ← Action Line
                 ┃
                 ┃   ✗ Behavior fails
                 ┃  (below the Action Line)
            LOW  ┃
                 ┗━━━━━━━━━━━━━━━━━━━━━━━━━
                 HARD                    EASY
                        Ability

The Action Line: When motivation and ability are sufficient, a prompt causes the behavior; below the line, no prompt works. High motivation compensates for low ability and vice versa. The reliable strategy is making behaviors easier (move right), not pumping up motivation (move up).

See: references/behavior-model.md when you need the curve mechanics behind this model — the full Action Line math, behavior types (dot/span/path), and a step-by-step failure diagnostic for a behavior that isn't happening.

Scoring

Goal: 10/10. The six Quick Diagnostic rows are the single source of score-movers. Rate each pass/fail, then start at 10 and subtract per failing row: low motivation or below the Action Line (rows 1-2) cost -2 each; prompts, celebration, bottleneck, and scaling (rows 3-6) cost -1.5 each. A design that passes all six scores 10; one that fails every row scores 0. Map to bands: 9-10 = behavior reliably crosses the Action Line at low motivation, prompts are event/anchor-tied, key actions are celebrated; 5-6 = depends on a motivation spike or optimizes a non-bottleneck factor; <=3 = core action below the Action Line, prompts are spam, no habit wiring. Always state the score and name the specific failing rows.

The Three Elements

1. Motivation

Core concept: Motivation is the energy for action, driven by three core motivators, each with two sides: Sensation (pleasure/pain), Anticipation (hope/fear), Belonging (acceptance/rejection). It is powerful but unreliable.

Why it works: Motivation comes in waves — it spikes (New Year's resolutions, product launches) and crashes (day 3, week 2). Products that depend on high motivation fail when the wave recedes; the best designs work at the trough.

Key insights:

  • "Motivation is unreliable. Ability is not." — BJ Fogg
  • Design for low-motivation moments, not peak excitement
  • Motivation-first tactics (inspiring videos, aspirational messaging) produce spikes, not sustained behavior
  • Match required motivation to behavior difficulty — hard behaviors need high motivation

Product applications:

Copy patterns:

  • "Takes 30 seconds" (signals ease, lowers motivation needed)
  • "Join 50,000 teams who..." (belonging motivator)
  • "Don't lose your 7-day streak" (anticipation/fear motivator)

Ethical boundary: A fear motivator (the streak pattern above) is fair only when the loss is real and user-owned (their data, their progress); never invent a loss that exists solely to drive a session.

See: references/motivation-waves.md for the three motivators, motivation waves, and designing for troughs.

2. Ability

Core concept: Ability is the capacity to do the behavior — a function of the scarcest resource across six factors (the Ability Chain). If any single link is too weak, the behavior breaks.

Why it works: Unlike motivation, ability can be systematically engineered: every removed field, eliminated step, and preset default moves the behavior right on the model, crossing the Action Line even at low motivation. The Ability Chain gives you the diagnostic — find the weakest link and fix it.

Key insights:

  • Six factors: Time, Money, Physical Effort, Mental Effort, Social Deviance, Non-Routine
  • Simplicity is a function of the scarcest resource — find the bottleneck, not the most obvious factor
  • "Simplicity changes behavior" — BJ Fogg
  • Starter Steps: shrink the behavior to the tiniest version (2 minutes → 30 seconds → one field)
  • Defaults are the most powerful ability tool — users rarely change them

Product applications:

Copy patterns:

  • "One click to get started" (time + physical effort)
  • "No technical skills needed" (mental effort)
  • "Works just like tools you already use" (non-routine)

Ethical boundary: Reduce friction only on genuinely valuable behaviors — never make it too easy to overspend, over-share, or delete important data without confirmation.

See: references/ability-chain.md for the six factors in detail, friction audit templates, and simplification strategies.

3. Prompt

Core concept: The prompt says "do it now." Without one, behavior doesn't happen regardless of motivation and ability. Three types: Person Prompts (internal reminders), Context Prompts (environmental cues), Action Prompts (designed triggers from the product).

Why it works: Teams assume motivation + ability is enough — it isn't, not without a well-timed prompt. But prompts only work above the Action Line: a push notification to someone lacking motivation or ability is spam.

Key insights:

  • A prompt at the wrong moment is noise; at the right moment, magic
  • Anchor moments tie new behaviors to existing routines ("After I open Slack, I will...")
  • Prompt fatigue is real — every unnecessary prompt degrades the value of future ones

Product applications:

Copy patterns:

  • "Your weekly report is ready" (context prompt — real event)
  • "One thing left to complete your setup" (action prompt with progress)
  • Never: "We miss you!" (product need, not user need)

Ethical boundary: Every prompt must pass the test "Would I appreciate receiving this right now?" — if it serves a product metric (DAU, re-engagement) but not the user's current goal, cut it.

See: references/prompt-design.md for prompt types, timing strategies, notification design, and anchor moments.

Tiny Habits Method

The practical application of B=MAP: make behaviors so small they need almost no motivation, anchor them to existing routines, and celebrate immediately.

The Recipe

After I [ANCHOR MOMENT], I will [TINY BEHAVIOR], then I [CELEBRATION].
  • Anchor Moment: an existing routine that reliably happens (opening an app, finishing a meeting, morning coffee).
  • Tiny Behavior: the smallest version of the target behavior — not "write a report" but "open the report template."
  • Celebration: an immediate positive emotion that wires the habit. Repetition alone isn't enough — you need the feeling of success.

Starter Steps

Every target behavior has a Starter Step — the tiniest meaningful version:

Scaling Behaviors

Once wired, tiny behaviors grow naturally: open dashboard → check a few metrics → customize → automatic morning habit. Never force scaling — let motivation and momentum drive expansion. The tiny version is the foundation, not a failure.

See: references/tiny-habits.md for the full Tiny Habits recipe, celebration techniques, and scaling patterns.

Behavior Design Process

Fogg's systematic process for lasting behavior change:

Step 1: Clarify the Aspiration

What outcome does the user want — their aspiration, not the product's goal ("stay on top of my team's progress", not "increase DAU").

Step 2: Explore Behavior Options

List all possible behaviors that could achieve the aspiration. Be exhaustive — don't commit yet.

Step 3: Match Behaviors

Assess each for motivation and ease; plot on a 2×2 of impact vs. feasibility (Focus Mapping).

Step 4: Start Tiny

Shrink the best-matched behavior to its Starter Step; design the prompt; add celebration.

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