Skip to content
cccskills
FreePublished on GitHub

retention-loops

Use when designing product-led retention — habit formation, trigger-action-reward, network vs single-user loops. Triggers on 'why don't users come back', 'design a habit loop'.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md8.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

retention-loops

When to use

  • D30 retention is flat or declining and the team cannot name a single product loop that pulls the user back — retention is treated as marketing's problem, not the product's.
  • A new feature shipped but did not move retention — there is no closed loop between trigger, action, and reward, so the feature is a destination, not a habit.
  • The product depends on a network effect that has not been instrumented as a loop — invites, content, or data are produced but the loop that pulls the next user back is unwritten.

Do NOT use to fix days 0–30 onboarding friction (route to onboarding-design), classify churn causes (route to churn-prevention), or design human-led account-expansion plays (route to expansion-playbook).

Cognition cluster

  • Mental model 14 — Meadows leverage points. A retention loop is a feedback structure: the leverage sits in the loop's gain (how strong the reward is) and delay (how long until the reward lands), not in the surface UI. Pick the leverage point — gain or delay — over surface polish. See docs/contracts/mental-models.md § 14.
  • Mental model 8 — Compounding. A loop with even small gain per cycle compounds across cohorts; a one-time activation bump does not. Verify which loops compound before investing cycles into them. See mental-models.md § 8.
  • Mental model 18 — Pull vs. push. A trigger the user pulls (intrinsic need surfaced by the product) compounds; a trigger the vendor pushes (marketing notification firing) decays the channel and trains the user to mute. See mental-models.md § 18.
  • Context-spine — product + customer-segment + funnel-stage. Read the product slot for which capability can carry a loop (a loop is only as strong as the action it routes through), the customer-segment slot for which segments have the latent need the loop addresses, and the funnel-stage slot for where the loop sits relative to activation and paid. See context-spine.

Procedure

Step 0: Inspect — name the current loops, if any

Inspect the product. For each suspected loop, write the closed form: "<trigger> → <action> → <reward> → <trigger again>." If the loop cannot be written closed, it is not a loop; it is a funnel ending. Inspect whether the reward arrives quickly enough to reinforce the action — verify the delay against the segment's attention cycle.

Step 1: Classify each loop as single-user vs network

  1. Single-user loop — trigger and reward both originate from the same user (a daily-summary email triggered by yesterday's activity).
  2. Network loop — trigger or reward involves another user (a teammate's comment, a partner's reply, a customer's reaction).

Network loops compound harder but require minimum-viable-network density; below density they look broken. Classify before investing.

Step 2: Audit the gain and the delay per loop

For each loop:

  1. Gain per cycle — what observable utility does the user receive (information, social affirmation, time saved, reduced error)? Gain measured as the user's revealed willingness to repeat the action.
  2. Delay — time from trigger to reward. A delay longer than the segment's attention window kills the loop regardless of gain.
  3. Decay — does the loop weaken when the user already has the reward? Most product loops decay; design the next loop before the first decays.

Step 3: Pick the binding loop and isolate it

Of the loops named, pick the one whose gain × frequency × eligible segment-size is largest. Verify the loop is intrinsic-pull, not vendor-push: confirm the trigger originates from a user action or state, not from a marketing schedule. A push-trigger labelled as a loop will burn the channel.

Step 4: Design the missing step, not the missing UI

If the binding loop is broken, the broken step is almost always: trigger missing, action too far from trigger, reward delayed, or no path back to next trigger. Design the missing step, not a UI tweak. UI tweaks polish a loop that already closes; they do not close an open one.

Step 5: Hand back

Hand the loop inventory, the binding-loop selection with gain / delay / decay, and the step-level redesign to the implementing team and to activation-design — activation is the loop's first cycle, and the activation event must complete the first cycle of the binding loop. Retention work without a named loop is rearranging notifications.

Related Skills

WHEN to use this

  • Designing or auditing product-led retention loops.
  • Selecting the binding loop and redesigning its missing step.

WHEN NOT to use this

When the agent should load this

  • "Why don't users come back?"
  • "Design a habit loop for feature X."
  • "Is this loop single-user or network?"
  • "Welcher Loop tr\u00e4gt eigentlich unsere Retention?"

Output

  1. loop-inventory.md — every named loop in closed form: trigger → action → reward → next trigger, with single-user vs network tag.
  2. gain-delay-audit.md — per-loop gain · delay · decay · eligible-segment size · revealed repeat-rate.
  3. binding-loop-redesign.md — selected loop, the broken step, and the redesign in step terms (not UI terms).

Gotcha

  • A loop whose reward arrives outside the segment's attention window will look broken even when gain is high; delay kills loops more often than gain does.
  • A network loop below minimum-viable density behaves like an open funnel; instrumenting it and designing it before density is theatre.
  • "Notifications fire daily" is not a loop; it is a push schedule. A loop needs a closed return path from reward to next trigger that the user — not the vendor — closes.

Do NOT

  • Do NOT invest in surface UI on a loop that does not close; the loop closes by adding a step, not polishing one.
  • Do NOT instrument network loops as single-user loops; the metric will look broken until the network reaches density.
  • Do NOT design more than one binding loop at a time; concurrent loop changes destroy the signal.

Runnable example

Mid-market collaboration tool, D30 retention 41 %, two suspected loops named.

  • Loop inventory — (L1) user receives daily summary → opens product → reviews changes → leaves a comment → teammate notified (network). (L2) user creates a doc → bookmark surfaces in nav → user reopens (single-user).
  • Gain–delay audit — L1 gain medium, delay 24 h (within attention window), decay low (network refreshes); L2 gain low, delay 0, decay high (bookmark stale within a week).
  • Binding loop — L1 selected (gain × frequency × segment-size dominates). Broken step: "teammate notified" fires but does not route teammate back to the originating doc — the loop opens.
  • Redesign — add teammate-return path: notification deep-links into the doc at the commented passage; verify with cohort A/B at 4-week horizon. Predicted: D30 +6 pp ± 3 pp.
  • Hand-off — loop inventory + redesign → eng team; activation event redefinition (one comment + one teammate notified) handed to activation-design.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use when reviewing UI for accessibility — WCAG 2.2 AA, keyboard nav, focus, ARIA, contrast, screen-reader semantics — even on 'is this a11y-OK?' or 'mach das barrierefrei'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 21, 2026

Use when defining or auditing the activation event — aha-moment selection, retention correlation, falsifiable definition. Triggers on 'what is our aha moment', 'redefine activation'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 21, 2026

Use when capturing an architectural decision — file naming, next ADR number, Status / Context / Decision / Consequences, index regen; fires even without saying 'ADR'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 21, 2026

Adversarial critique — devil's advocate, stress-test, honest teardown ('poke holes', 'be brutal', 'was hältst du davon'); explicit request only. Routine code or design review → code-review.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 21, 2026

Use when reading, creating, or updating agent documentation, module docs, roadmaps, or AGENTS.md. Understands the full .augment/, agents/, and copilot-instructions structure.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 21, 2026

Use for an adversarial red-team / blue-team / auditor review of an AI agent's CONFIG + behaviour (rules, skills, MCP, hooks, permissions) — attack-chain → defensive-gap list, not a code audit.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 21, 2026

See all skills by event4u-app

Report a problem with this skill