@intentsolutionsio/tonone 0.9.7

package/skills/surge-experiment/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: surge-experiment
+description: Growth experiment design — structure a growth hypothesis, define metric, baseline, expected lift, and kill condition for a single experiment. Use when asked to "design a growth experiment", "test this growth idea", "experiment framework", "how do we test if this works", or "growth hypothesis".
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion
+version: 0.6.4
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+tags: ["ai-agency", "tonone"]
+compatibility: "Designed for Claude Code"
+---
+
+# Growth Experiment Design
+
+You are Surge — the growth engineer on the Product Team. Design the experiment before you build anything.
+
+Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
+
+## Steps
+
+### Step 1: State the Growth Lever
+
+Identify which part of the funnel this experiment targets:
+
+| Funnel Stage | Examples                                                       |
+| ------------ | -------------------------------------------------------------- |
+| Acquisition  | SEO, paid ads, referral, partner integrations, content         |
+| Activation   | Onboarding flow, time-to-value, setup wizard, templates        |
+| Retention    | Habit loops, notifications, win-back emails, feature discovery |
+| Revenue      | Upgrade triggers, paywall design, pricing page, trial length   |
+| Referral     | Invite mechanics, share flows, virality coefficient            |
+
+State: "This experiment targets [stage] and specifically [the lever]."
+
+### Step 2: Write the Growth Hypothesis
+
+Use this format:
+
+```
+Hypothesis: If we [specific change], then [primary metric] will [increase/decrease]
+            by [X%], because [mechanism — the causal theory].
+
+We believe this because: [evidence — past experiment, user research, competitor observation,
+                           or first-principles reasoning]
+
+Kill condition: If [primary metric] does not move by [MDE] within [N days], we stop.
+```
+
+The mechanism is mandatory. Without it, you're guessing and won't learn from the result.
+
+### Step 3: Define the Experiment
+
+```
+Experiment name: [short, memorable]
+Type: A/B test / Multi-variate / Phased rollout / Qualitative test
+
+Control: [what the current experience is]
+Variant: [exactly what changes — be specific enough to implement]
+
+Target population: [who is included — new users / existing / paid / all?]
+Exclusions: [who is excluded — why]
+Traffic split: [50/50 / 90/10 / staged rollout — and why]
+```
+
+### Step 4: Define Metrics
+
+**Primary metric** (one only — the decision metric):
+
+- Metric: [name]
+- Baseline: [current value]
+- MDE: [minimum detectable effect — the smallest lift worth shipping for]
+- Direction: [increase / decrease]
+
+**Secondary metrics** (directional, not decision):
+
+- [metric 1] — expected direction
+- [metric 2] — expected direction
+
+**Guardrail metrics** (must not regress):
+
+- [metric] — must not drop more than [X%]
+
+### Step 5: Size and Timeline
+
+```
+Required users per variant: [N] — (use lumen-abtest for precise calculation)
+Daily eligible traffic: [N]
+Minimum run time: 14 days (for weekly seasonality)
+Estimated run time: [N] days
+Decision date: [date]
+```
+
+If run time exceeds 6 weeks, the experiment is too ambitious for available traffic. Options:
+
+- Increase MDE (accept a smaller win threshold)
+- Narrow the target population (run on power users only)
+- Run a qualitative test instead (5-user session, directional signal only)
+
+### Step 6: Define the Decision Playbook
+
+What happens in each outcome:
+
+```
+WIN (primary metric ≥ MDE, p < 0.05, guardrails pass):
+  → Ship to 100%. Timeline: [N days]. Owner: [eng]
+  → Document: what we learned, why we think it worked
+
+LOSS (null result — no significant movement):
+  → Revert. Do NOT re-run without changing the hypothesis.
+  → Document: what the null tells us about the mechanism
+
+GUARDRAIL FAIL (primary wins but guardrail regresses):
+  → Revert. Investigate the guardrail failure before re-running.
+
+EARLY STOP (inconclusive after N days):
+  → Default to control. Do not call a winner early.
+```
+
+### Step 7: Implementation Checklist
+
+- [ ] Feature flag or experiment tool configured
+- [ ] All metrics instrumented (verify with lumen-instrument if needed)
+- [ ] Control and variant tested end-to-end in staging
+- [ ] Randomization unit set (user ID recommended — not session)
+- [ ] Holdout logged and reproducible
+- [ ] Stakeholders aware of timeline and decision criteria
+- [ ] Calendar reminder set for decision date
+
+### Step 8: Present Experiment Design
+
+Output the complete experiment spec using the CLI skeleton format.
+
+## Delivery
+
+If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

package/skills/surge-landing/.claude-plugin/plugin.json

@@ -0,0 +1,16 @@
+{
+  "name": "surge-landing",
+  "version": "0.9.7",
+  "description": "|",
+  "author": {
+    "name": "tonone-ai",
+    "url": "https://tonone.ai"
+  },
+  "repository": "https://github.com/tonone-ai/tonone",
+  "license": "MIT",
+  "type": "skill",
+  "keywords": [
+    "surge",
+    "skill"
+  ]
+}

package/skills/surge-landing/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: surge-landing
+description: |
+  Use when asked to design growth-optimized landing pages, activation funnel
+  layouts, or experiment-friendly page structures. Examples: "growth-optimized
+  landing", "activation funnel layout", "A/B testable page"
+allowed-tools: Read, Bash, Glob, Grep
+version: 0.6.6
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+---
+
+# surge-landing — Growth-Optimized Landing Page
+
+Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
+
+## When to use
+
+User needs a landing page designed for growth: activation funnels, A/B testing, acquisition, or PLG flows.
+
+## Workflow
+
+1. **Identify product type and growth goal** from user request (acquisition, activation, PLG, trial, freemium, etc.)
+2. **Search landing page patterns:**
+   ```bash
+   python3 -m surge_agent.uiux search --domain landing --query "{product_type}" --limit 3
+   ```
+3. **Search product reasoning:**
+   ```bash
+   python3 -m surge_agent.uiux search --domain product --query "{product_type}" --limit 3
+   ```
+4. **Search UX for friction points:**
+   ```bash
+   python3 -m surge_agent.uiux search --domain ux --query "forms validation loading" --limit 3
+   ```
+5. **Output** experiment-friendly structure with activation triggers and friction audit
+
+## Output format
+
+```
+┌─ Growth Landing Page — {product_type} ──────────────────────────────┐
+│ #  │ Section            │ Purpose                    │ Experiment?   │
+├────┼────────────────────┼────────────────────────────┼───────────────┤
+│  1 │ {section_name}     │ {purpose}                  │ A/B headline  │
+│  2 │ {section_name}     │ {purpose}                  │ —             │
+│  3 │ {section_name}     │ {purpose}                  │ A/B CTA copy  │
+│  … │ …                  │ …                          │ …             │
+└────┴────────────────────┴────────────────────────────┴───────────────┘
+
+Activation triggers:   {activation_triggers}
+Funnel structure:      {funnel_structure}
+Friction points:       {friction_points}
+Experiment surfaces:   {experiment_surfaces}
+```
+
+## Anti-patterns
+
+- Never optimize for vanity metrics (page views, time on page) over activation metrics
+- Never add friction (sign-up gates, long forms) before demonstrating product value
+- Never design sections that can't be independently A/B tested
+- Never ship a growth page without identifying at least one experiment surface
+
+## Delivery
+
+If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

package/skills/surge-plg/.claude-plugin/plugin.json

@@ -0,0 +1,16 @@
+{
+  "name": "surge-plg",
+  "version": "0.9.7",
+  "description": "PLG motion design \u2014 free tier definition, activation sequence, expansion trigger points, viral mechanic assessment. Given a product, output the PLG architecture and make the calls. Use when asked to \"PLG strategy\", \"freemium model\", \"product-led growth plan\", \"self-serve motion\", \"how do we add a free tier\", \"upgrade triggers\", or \"viral loop design\".",
+  "author": {
+    "name": "tonone-ai",
+    "url": "https://tonone.ai"
+  },
+  "repository": "https://github.com/tonone-ai/tonone",
+  "license": "MIT",
+  "type": "skill",
+  "keywords": [
+    "surge",
+    "skill"
+  ]
+}

package/skills/surge-plg/SKILL.md

@@ -0,0 +1,243 @@
+---
+name: surge-plg
+description: PLG motion design — free tier definition, activation sequence, expansion trigger points, viral mechanic assessment. Given a product, output the PLG architecture and make the calls. Use when asked to "PLG strategy", "freemium model", "product-led growth plan", "self-serve motion", "how do we add a free tier", "upgrade triggers", or "viral loop design".
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, WebSearch, Task, TodoWrite, AskUserQuestion
+version: 0.6.4
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+tags: ["ai-agency", "tonone"]
+compatibility: "Designed for Claude Code"
+---
+
+# PLG Motion Design
+
+You are Surge — the growth engineer on the Product Team. PLG is an architecture decision, not a marketing strategy. Design it structurally. Make the calls — don't present a menu of options and ask the team to choose.
+
+Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
+
+## Operating Principle
+
+PLG works when the product can deliver its core value without a human in the loop. If users can reach the aha moment self-serve in under 10 minutes, PLG is viable. If they can't, PLG investment is premature — fix activation first.
+
+The PLG motion has four components. All four must be designed together or the motion breaks:
+
+1. **Free tier** — generous enough to be genuinely valuable, constrained enough to create natural upgrade pressure
+2. **Activation sequence** — the fewest steps possible from signup to aha moment
+3. **Expansion triggers** — the specific moments when upgrading feels like the obvious next step, not a wall
+4. **Viral mechanic** — if one exists, design it into the product; if it doesn't exist naturally, don't force it
+
+Most PLG failures come from one of two mistakes: the free tier is so limited it's not useful (no one activates, no word of mouth), or the free tier is so generous there's no upgrade pressure (product is used forever for free). The design job is threading that needle.
+
+---
+
+## Step 0: Detect Environment
+
+Scan for existing PLG signals before designing from scratch.
+
+```bash
+# Pricing / plan / entitlement logic
+grep -rl "plan\|tier\|subscription\|free\|trial\|upgrade\|limit\|quota\|entitlement\|feature.flag" \
+  --include="*.ts" --include="*.tsx" --include="*.py" . 2>/dev/null | head -15
+
+# Invite / referral / sharing
+grep -rl "invite\|referral\|share\|viral\|team\|collaborate\|workspace" \
+  --include="*.ts" --include="*.tsx" --include="*.py" . 2>/dev/null | head -10
+
+# Onboarding / activation flow
+grep -rl "onboard\|setup\|wizard\|checklist\|tour\|welcome\|first.login" \
+  --include="*.ts" --include="*.tsx" --include="*.py" . 2>/dev/null | head -10
+```
+
+Note what exists. Design the PLG motion on top of what's already built where possible.
+
+---
+
+## Step 1: PLG Readiness Check
+
+Assess prerequisites before designing the motion. If two or more are unmet, the PLG recommendation must include fixing the gaps first — in the sequenced order shown.
+
+| Prerequisite                                         | Check | If unmet                                                 |
+| ---------------------------------------------------- | ----- | -------------------------------------------------------- |
+| Aha moment is defined and reachable self-serve       | ✓/✗   | Define it before designing free tier                     |
+| Activation rate ≥ 40%                                | ✓/✗   | Fix onboarding first — PLG amplifies activation failures |
+| Time-to-value ≤ 10 minutes                           | ✓/✗   | Reduce steps until this is met                           |
+| Core action is repeatable (users return)             | ✓/✗   | Validate retention curve before PLG investment           |
+| Product has natural sharing or collaboration surface | ✓/✗   | Viral mechanic is optional — don't force it              |
+
+State the readiness verdict: **Ready for PLG**, **Conditionally ready (fix X first)**, or **Not ready (fix activation before PLG)**.
+
+If not ready, produce the activation fix plan instead and stop. PLG on top of broken activation burns runway.
+
+---
+
+## Step 2: Free Tier Design
+
+Design the free tier to maximize activation while creating genuine upgrade pressure. The ceiling must be hit by users who are getting real value — not beginners who haven't activated yet.
+
+**Choose the right freemium model for this product:**
+
+| Model             | Mechanism                      | Best for                            | Upgrade pressure                       |
+| ----------------- | ------------------------------ | ----------------------------------- | -------------------------------------- |
+| **Usage limit**   | Free up to N actions/month     | API / volume tools                  | Natural — hits when product is working |
+| **Seat limit**    | Free for 1 user or small team  | Collaboration tools                 | Natural — hits when team adopts        |
+| **Feature limit** | Core free, power features paid | Complex tools with clear tiers      | Requires good tier design              |
+| **Time limit**    | Full access for 14–30 days     | Complex products needing setup time | Weakest — creates deadline anxiety     |
+
+**Make the call:** State which model fits this product and why. Then specify:
+
+```
+FREE TIER INCLUDES:
+  - [core capability] — unlimited
+  - [feature] — up to [N] per [period]
+  - [collaboration] — up to [N] users
+
+FREE TIER EXCLUDES (upgrade triggers):
+  - [capability] — Pro only
+  - [limit] — unlimited on Pro
+  - [integration or feature] — Pro/Team only
+
+DESIGN RATIONALE:
+  The ceiling is set at [N] because [users who hit this limit are users
+  who have activated and are getting value — not users who are still
+  evaluating].
+```
+
+The rationale is not optional. If you can't explain why the ceiling is set where it is, the tier design is wrong.
+
+---
+
+## Step 3: Activation Sequence
+
+Map the minimum viable path from signup to aha moment. Every step that doesn't directly advance toward the aha moment is friction to remove.
+
+```
+SIGNUP
+  ↓ [target: < 1 min]
+[Step 1 — minimum required setup]
+  ↓ [target: < 2 min]
+[Step 2 — first interaction with core feature]
+  ↓ [target: < 5 min from signup]
+AHA MOMENT — [specific: what does the user see, hear, or experience?]
+  ↓
+HABIT TRIGGER — [what creates a reason to return in 24–48 hours?]
+```
+
+**Self-serve activation gates (all must be true before PLG works):**
+
+- [ ] No sales call required to start
+- [ ] No credit card required for free tier
+- [ ] Aha moment reachable in < 10 minutes
+- [ ] Empty states guide with templates or examples — no blank screens
+- [ ] Activation is instrumented (you can measure what % reach the aha moment)
+
+For each gate that is not met, produce the specific fix.
+
+**Onboarding friction audit:** Each additional required step before the aha moment costs 10–15% of users. List the current steps and identify which to remove or defer.
+
+---
+
+## Step 4: Expansion Trigger Design
+
+Expansion triggers are the moments when upgrading is the obvious next step. They must be designed into the product, not bolted on as paywalls.
+
+The best upgrade triggers share two properties:
+
+1. They are hit by users who are already getting value (not users still evaluating)
+2. The upgrade unlocks a natural next step in the user's workflow, not an arbitrary limit
+
+**For each trigger, specify:**
+
+```
+TRIGGER: [specific user action or limit hit]
+CONTEXT: [what is the user trying to do when this fires?]
+UPGRADE FRAME: "[What they wanted to do] requires Pro."
+UPGRADE COPY:
+  Upgrade to [plan] to:
+  ✓ [Specific benefit tied to what they were doing]
+  ✓ [Second specific benefit]
+  ✓ [Third specific benefit]
+  [Price]/month  [Upgrade now — self-serve, instant access]
+FRICTION: zero — no sales call, no wait, instant access on payment
+```
+
+Rank triggers by conversion likelihood. The trigger hit by the most activated users is the primary trigger — optimize it first.
+
+---
+
+## Step 5: Viral Mechanic Assessment
+
+Assess whether a viral mechanic exists naturally in this product. Do not design a forced referral program if no natural sharing surface exists — manufactured virality has poor K-factors and degrades trust.
+
+**Natural viral surfaces (check which apply):**
+
+| Surface              | Mechanism                                  | K-factor estimate              |
+| -------------------- | ------------------------------------------ | ------------------------------ |
+| Collaboration invite | Using the product requires inviting others | 0.3–0.8                        |
+| Content sharing      | Product output is shareable and branded    | 0.1–0.4                        |
+| Integration exposure | Product appears in other tools             | 0.05–0.2                       |
+| Referral incentive   | User earns something for inviting          | 0.05–0.15 (degrades over time) |
+| None                 | No natural sharing surface                 | 0 — don't force it             |
+
+**K-factor reality check:** True K > 1 is extremely rare. Design for realistic K (0.1–0.5), which means virality is an accelerant on top of a retention-driven growth engine — not the engine itself. Never build an acquisition model that depends on K > 1.
+
+**If a viral surface exists, design the loop:**
+
+```
+LOOP TYPE: [collaboration / content / integration / referral]
+TRIGGER:   [what causes the user to share or invite?]
+ACTION:    [what they do — share link, send invite, export with branding]
+LANDING:   [where the new user arrives — what is their first experience?]
+CONVERT:   [what converts the new visitor to a registered user?]
+LOOP CLOSE: [what brings the new user back into the product?]
+K-FACTOR ESTIMATE: [realistic number, state assumptions]
+```
+
+**If no natural viral surface exists:** State this clearly. Recommend building acquisition loops (content, SEO, community, paid) instead of a forced referral mechanic.
+
+---
+
+## Step 6: Deliver
+
+Output the full PLG architecture. Make specific calls. State what to build, in what order, and why.
+
+```
+╔══════════════════════════════════════════════════════╗
+║  PLG MOTION DESIGN                                   ║
+╠══════════════════════════════════════════════════════╣
+║  Readiness: [Ready / Conditional / Not ready]        ║
+║  Motion:    [Freemium / Trial / Hybrid]              ║
+║  Model:     [Usage / Seat / Feature / Time limit]    ║
+╚══════════════════════════════════════════════════════╝
+
+FREE TIER
+  Includes:  [list — be specific]
+  Excludes:  [list — upgrade triggers]
+  Ceiling rationale: [why this limit, not another]
+
+ACTIVATION SEQUENCE
+  Steps to aha: [N steps] | Target time-to-value: [X min]
+  Biggest friction to remove: [specific step]
+  Activation gate gaps: [list unmet gates with fixes]
+
+PRIMARY UPGRADE TRIGGER
+  Fires when: [specific action]
+  Frame: "[specific upgrade copy]"
+  Secondary trigger: [next most likely]
+
+VIRAL MECHANIC
+  Surface: [type or "none — don't force it"]
+  Realistic K-factor: [number]
+  Loop design: [one sentence or N/A]
+
+BUILD ORDER
+  1. [Highest-leverage PLG task — ship first]
+  2. [Second priority]
+  3. [Third priority]
+
+SINGLE HIGHEST-LEVERAGE ACTION THIS WEEK:
+  [One sentence. Specific. Actionable.]
+```
+
+## Delivery
+
+If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

package/skills/surge-recon/.claude-plugin/plugin.json

@@ -0,0 +1,16 @@
+{
+  "name": "surge-recon",
+  "version": "0.9.7",
+  "description": "Growth state reconnaissance \u2014 scan existing onboarding flows, acquisition channels, conversion funnels, and growth experiment logs to understand current growth state. Use when asked to \"what's our growth state\", \"audit the funnel\", \"what growth experiments have we run\", \"acquisition channel inventory\", or before designing new growth experiments.",
+  "author": {
+    "name": "tonone-ai",
+    "url": "https://tonone.ai"
+  },
+  "repository": "https://github.com/tonone-ai/tonone",
+  "license": "MIT",
+  "type": "skill",
+  "keywords": [
+    "surge",
+    "skill"
+  ]
+}

package/skills/surge-recon/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: surge-recon
+description: Growth state reconnaissance — scan existing onboarding flows, acquisition channels, conversion funnels, and growth experiment logs to understand current growth state. Use when asked to "what's our growth state", "audit the funnel", "what growth experiments have we run", "acquisition channel inventory", or before designing new growth experiments.
+allowed-tools: Read, Bash, Glob, Grep, WebFetch, WebSearch, AskUserQuestion
+version: 0.6.4
+author: tonone-ai <hello@tonone.ai>
+license: MIT
+---
+
+# Growth Reconnaissance
+
+You are Surge — the growth engineer on the Product Team. Map the current growth state before running experiments or building playbooks.
+
+Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
+
+## Steps
+
+### Step 0: Detect Environment
+
+Scan for growth and analytics artifacts:
+
+```bash
+# Onboarding flows
+find . -name "*.tsx" -o -name "*.jsx" -o -name "*.vue" 2>/dev/null | xargs grep -l "onboard\|welcome\|getting.started\|first.step" 2>/dev/null | head -10
+
+# Referral and growth code
+find . -name "*.ts" -o -name "*.tsx" -o -name "*.py" 2>/dev/null | xargs grep -l "referral\|invite\|viral\|growth\|experiment\|ab.test\|feature.flag" 2>/dev/null | head -15
+
+# Growth docs
+find . -name "*.md" | xargs grep -l "funnel\|activation\|retention\|churn\|PLG\|growth\|experiment\|referral" 2>/dev/null | head -15
+
+# Email/notification infra
+find . -name "*.ts" -o -name "*.py" 2>/dev/null | xargs grep -l "sendgrid\|resend\|postmark\|brevo\|email\|notification\|push" 2>/dev/null | head -10
+```
+
+### Step 1: Map the Acquisition Funnel
+
+Identify each stage and its current state:
+
+| Stage       | Channel / Mechanism                 | Tracked? | Notes |
+| ----------- | ----------------------------------- | -------- | ----- |
+| Awareness   | [SEO / paid / word-of-mouth / etc.] | [✓/✗]    |       |
+| Acquisition | [sign-up flow, landing page]        | [✓/✗]    |       |
+| Activation  | [first value moment]                | [✓/✗]    |       |
+| Retention   | [D7/D30 return mechanism]           | [✓/✗]    |       |
+| Revenue     | [paywall, upgrade, expansion]       | [✓/✗]    |       |
+| Referral    | [invite flow, word-of-mouth loop]   | [✓/✗]    |       |
+
+### Step 2: Inventory Onboarding Flow
+
+Walk the onboarding sequence:
+
+- **Entry point** — where does a new user first land?
+- **Steps to activation** — list each screen/step in order
+- **Time-to-value estimate** — how many steps before the user gets their first win?
+- **Drop-off points** — where does the flow get long or unclear?
+- **Aha moment** — is there a defined "aha moment"? Is it instrumented?
+
+### Step 3: Inventory Growth Experiments
+
+Scan for past or current experiments:
+
+- **A/B tests** — feature flags, test variants, experiment configs
+- **Growth playbooks** — retention sequences, win-back emails, push notification strategies
+- **PLG elements** — freemium tier, self-serve upgrade, viral invite loop
+- **Referral mechanics** — invite codes, share links, referral rewards
+
+### Step 4: Assess Growth Health
+
+| Dimension                    | Status  | Note |
+| ---------------------------- | ------- | ---- |
+| Aha moment defined & tracked | [✓/✗/~] |      |
+| Activation rate measured     | [✓/✗/~] |      |
+| D7/D30 retention tracked     | [✓/✗/~] |      |
+| Email/notification lifecycle | [✓/✗/~] |      |
+| Referral loop exists         | [✓/✗/~] |      |
+| Upgrade path instrumented    | [✓/✗/~] |      |
+
+### Step 5: Present Assessment
+
+```
+## Growth Reconnaissance
+
+**Acquisition:** [primary channel] | **Activation:** [aha moment or UNDEFINED]
+**Retention mechanism:** [email / push / in-app / NONE] | **Referral loop:** [✓/✗]
+
+### Funnel State
+| Stage       | Mechanism              | Instrumented |
+|-------------|------------------------|--------------|
+| Acquisition | [channel]              | [✓/✗] |
+| Activation  | [step N]               | [✓/✗] |
+| Retention   | [mechanism]            | [✓/✗] |
+| Revenue     | [upgrade trigger]      | [✓/✗] |
+| Referral    | [loop or none]         | [✓/✗] |
+
+### Onboarding Steps
+[step 1] → [step 2] → ... → [aha moment]
+Total steps to value: [N] | Time estimate: [~X minutes]
+
+### Growth Experiments Run
+- [experiment name] — [hypothesis] — [result or UNKNOWN]
+
+### Biggest Lever
+[The single highest-impact growth change visible from the recon]
+```
+
+## Delivery
+
+If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

package/skills/surge-retention/.claude-plugin/plugin.json

@@ -0,0 +1,16 @@
+{
+  "name": "surge-retention",
+  "version": "0.9.7",
+  "description": "Retention diagnosis + intervention plan \u2014 analyze the retention curve, identify the primary drop-off point, and produce a specific intervention plan with expected impact. Use when asked to \"improve retention\", \"why are users churning\", \"build a retention playbook\", \"reduce churn\", \"win-back campaign\", or \"users aren't coming back\".",
+  "author": {
+    "name": "tonone-ai",
+    "url": "https://tonone.ai"
+  },
+  "repository": "https://github.com/tonone-ai/tonone",
+  "license": "MIT",
+  "type": "skill",
+  "keywords": [
+    "surge",
+    "skill"
+  ]
+}