grow-app skill

Grow an App

Your app has users who sign up and then quietly disappear — cohorts decay, daily actives are flat, the activation funnel leaks where it always has, and nothing looks obviously broken. This journey seals the bucket: it turns first-time users into activated, then habitual, then would-miss-it users across eight interactive phases. The agent asks before every decision and records the outcome in docs/, so the work resumes across sessions instead of restarting. Growth here is an engineering and design problem, not a bigger ad budget.

Core Principle

Fix the leaky bucket before pouring in acquisition: habit, activation, and retention come before any growth spend. This skill sequences the eight phases, asks every decision question, and records each choice in docs/. The constituent skills carry the method — invoke them rather than improvising their frameworks.

Journey Map

Phases 1-2 seal the loop and the funnel; 3-5 steer with evidence; 6 is the instrument panel; 7-8 are the finish and the ethical backstop. Take the lean-analytics baseline (Phase 6) early — before the Phase 1-2 fixes land — so every change is read against a pre-change number, then keep updating it. Habit formation is slow: read Phase 1's success against the "5% rule" (a habit has formed when 5%+ of users return unprompted), not a single cohort.

Operating Rules

1. Resume first. Before anything else, read docs/GROW-APP-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/GROW-APP-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/ --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 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. Retention before acquisition. Acquisition-oriented phases — the optional cold-start-problem, contagious, and crossing-the-chasm, plus any paid-growth work — stay locked while activation and retention sit below the bar set at intake; unlock them only once the cohort curve clears that bar. Every habit loop and reward must pass the Manipulation Matrix: build only what the maker would use and honestly believes materially improves users. When a tactic needs manufactured anxiety or loss aversion, replace it with one built on real value.

Intake

Run only on first start (no tracker). Ask:

1. What does the app do, and what core action does a retained user repeat? (defines the Hook loop and the OMTM)
2. What are the current retention numbers — day-1/7/30 or week-4 cohorts? (sets the Rule 8 acquisition bar; feeds lean-analytics)
3. Where does the activation funnel leak, and what is the first-run flow? (gates improve-retention)
4. Solo/small team or a full product trio (PM, designer, engineer)? (scales continuous-discovery and inspired-product)
5. Is the app a network/marketplace product, and do engaged users fail to convert to revenue? (flags optional cold-start-problem / monetizing-innovation)
6. What analytics and instrumentation exist today? (gates lean-analytics and every experiment)
7. Is retention broken by UX or performance rather than missing engagement? (if yes, route to improve-app first)

Skip heuristics: skip Phase 5 for a solo founder with no team to realign; defer Phase 7 until the loop and activation clear their bars; run Phase 3's cadence degraded if no user access exists yet. Then create the tracker from references/artifact-templates.md with every phase statused, and confirm the plan.

Done when docs/GROW-APP-PLAN.md exists with every phase statused and the user has confirmed the plan.

Phases

Phase 1 — Design the habit loop that brings users back (hooked-ux)

Purpose: Build the engine of return — a Hook loop strong enough that users come back on an internal trigger, not a paid notification.

Brief (fallback): The Hook Model runs Trigger → Action → Variable Reward → Investment. Migrate external triggers (push, email) to internal ones (an emotion — boredom, FOMO, anxiety). Make the action trivially simple. Make the reward variable across tribe/hunt/self. Sequence investment after the reward so it raises switching cost and loads the next trigger. A loop with one weak phase stalls, not half-works.

Invoke: Use the hooked-ux skill with the core loop and how daily-active users return today. Ask it to (a) map the loop across all four phases, rate each 0-10, and name the weakest, and (b) design honest variable-reward concepts powered by data you already have, each checked against the Manipulation Matrix.

Decide with the user:

• Which internal trigger (emotion) should pull users back — confirm one.
• Which single phase is weakest and gets the highest-leverage fix now — or defer if the loop is already forming (5%+ unprompted return).
• Which reward type to strengthen — tribe (social), hunt (resources), or self (mastery) — rejecting any concept that fails the Manipulation Matrix.

Artifact: Extend docs/PRODUCT.md ## Hook Model (trigger → action → variable reward → investment; weakest phase named). Update the tracker.

Done when: PRODUCT.md names the internal trigger and all four phases, the weakest phase and its fix are recorded, onboarding is re-engineered so a new user completes one full Hook cycle in the first session, and the user picked the fix to ship.

Phase 2 — Fix activation by making the first action almost effortless (improve-retention)

Purpose: Get new users to the loop by making the first meaningful action almost effortless.

Brief (fallback): B=MAP — behavior fires only when Motivation, Ability, and a Prompt converge. Motivation is unreliable; raise Ability instead. Simplicity is capped by the scarcest of six resources: time, money, physical effort, mental effort, social deviance, non-routineness. Shrink the target to a Starter Step that delivers value in under 30s, anchor it to an existing routine, and celebrate the win immediately.

Invoke: Use the improve-retention skill with the real activation flow step by step and the day-1/7/30 drop-offs. Ask for a B=MAP friction audit rating all six Ability-Chain factors, the scarcest resource named, a Starter Step redesign, and event-based prompt rules.

Decide with the user:

• Which is the scarcest Ability resource for the first action — fix that link first, not the obvious one.
• The Starter Step (tiniest valuable action) and its celebration moment.
• Which time-based prompts convert to event-based, dropping any that fail "would I appreciate this now?".

Artifact: Extend docs/PRODUCT.md ## Activation & Retention Plan (friction/moment | fix | owner | status). Update the tracker.

Done when: the scarcest resource is named, the Starter Step, celebration, and prompt changes are rows with owners, each day-1/7/30 drop-off is mapped to its likely B=MAP failure, and the user approved the fix list.

Phase 3 — Run continuous discovery so you stop guessing (continuous-discovery)

Purpose: Replace generic best-practice with a weekly stream of evidence about your own users.

Brief (fallback): Aim for at least one customer touchpoint per week. Build an Opportunity Solution Tree: outcome at the top → customer opportunities (needs/pains in the customer's words) → candidate solutions/experiments. Never leap outcome→solution. Interviews are story-based ("tell me about the last time you…"), captured as one-page snapshots. Test the riskiest leap-of-faith assumption first, cheaply.

Invoke: Use the continuous-discovery skill with the retention outcome and known churn patterns. Ask for an Opportunity Solution Tree, a current-state experience map of how churned users try to succeed today, a weekly story-based interview snapshot template, and an assumption map for the next planned feature.

Decide with the user:

• The single outcome at the top of the tree.
• Which two or three opportunities to pursue first.
• The weekly cadence and recruitment mechanism the team can actually sustain — set it now or run degraded.
• The riskiest leap-of-faith assumption inside the next feature (desirability, viability, feasibility, usability) and the cheapest test for it.

Artifact: Extend docs/PRODUCT.md ## Opportunity Solution Tree Notes, ## Outcome Roadmap (outcome/problem | job served | priority | status), and ## Discovery Cadence; extend docs/CUSTOMER.md ## Interview Evidence (date | who | facts | commitment). Update the tracker.

Done when: the tree's outcome and top opportunities are recorded, the cadence is scheduled, the first interview snapshot template exists, and the riskiest assumption has a cheap test designed.

Phase 4 — Replace debate with cheap experiments (lean-ux)

Purpose: Turn opportunities into falsifiable bets settled by behavior, not meetings.

Brief (fallback): Outcomes over outputs — value is the behavior change, not the deliverable. Write a hypothesis: "We believe [outcome] will happen if [persona] achieves [action] with [feature]," with the metric and threshold committed before the test. Match fidelity to risk (a paper prototype with five users finds ~85% of usability issues); reserve A/B tests for tuning a proven concept. When invalidated, remove from the backlog — don't defer.

Invoke: Use the lean-ux skill with the biggest current design debate or a top discovery opportunity. Ask for three hypothesis statements in the standard format, the lowest-fidelity experiment that could validate the top one, and its pre-committed metric, threshold, and timebox.

Decide with the user:

• Which hypothesis to test first.
• The experiment fidelity — the lowest that answers the actual question.
• The pass/fail line and what leaves the backlog if it fails.

Artifact: Extend docs/EXPERIMENTS.md ## Experiment Cards (hypothesis, type, primary metric + threshold, guardrail, decision rule) and ## Experiment Backlog (idea | ICE | status). Update the tracker.

Done when: at least one experiment card has a pre-committed threshold and decision rule, the backlog is triaged, and the user chose the first test.

Phase 5 — Build the right things with an empowered team (inspired-product)

Purpose: Move the team from feature factory to outcome ownership — problems to solve, not features to ship.

Brief (fallback): Empowered teams get problems, not backlogs, and answer for outcomes. Dual-track: discovery (what's worth building — addressing value, usability, feasibility, viability) runs continuously alongside delivery. Expect 10-20 discovery iterations per shipped feature. Give the team a product vision and an outcome-based roadmap so it can decide autonomously.

Invoke: Use the inspired-product skill with the top three backlog requests and the current roadmap. Ask for an opportunity assessment of each (objective, target user, problem, success measure, alternatives) and a one-paragraph vision plus a quarter of outcome-based roadmap items.

Decide with the user:

• Which backlog request has the strongest evidence — and which to kill before it reaches a sprint.
• The one-paragraph product vision.
• Whether the roadmap is reframed as problems + key results rather than dated features.

Artifact: Extend docs/PRODUCT.md ## Vision and ## Outcome Roadmap (outcome/problem | job served | priority | status). Update the tracker.

Done when: the vision paragraph exists, each of the three requests has a build/kill verdict, and the roadmap rows are outcomes, not features.

Phase 6 — Measure the one number that actually matters (lean-analytics)

Purpose: Point the whole team at the One Metric That Matters and expose the vanity metrics hiding the decay.

Brief (fallback): A good metric is comparative, a ratio/rate (not a cumulative total), and behavior-changing. Business model dictates which metrics matter; stage dictates sequencing (Empathy → Stickiness → Virality → Revenue → Scale). Weak retention = Stickiness stage, so retention is the OMTM — working a later stage first is the canonical mistake. Draw a line in the sand (target, date, miss response), pair the OMTM with a counter-metric, and cohort the data.

Invoke: Use the lean-analytics skill with the current dashboard/metrics and the business model. Ask it to flag vanity metrics, pick the Stickiness-stage OMTM plus a counter-metric, design a one-screen dashboard (OMTM big, ≤6 supporting), and a cohorted retention view.

Decide with the user:

• The OMTM and its counter-metric.
• The line in the sand — target, date, pre-committed miss response.
• Which current metrics are retired as vanity.