plugins/pm/skills/activation-analysis/SKILL.md
Analyze user activation using Setup → Aha → Habit framework. Identifies activation bottlenecks.
npx skillsauth add coalesce-labs/catalyst activation-analysisInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
/activation-analysis
Then provide:
I'll diagnose your activation funnel using Setup -> Aha -> Habit, identify the biggest bottleneck, and recommend specific fixes.
Output: Saved to thoughts/shared/pm/analyses/activation-analysis-[date].md
Time: ~15 min with data, ~25 min if defining stages from scratch
When to use: When diagnosing activation problems, improving onboarding, or measuring early product engagement
Framework source: Aakash Gupta's "Ultimate Guide to Activation" and "How to Measure Onboarding"
Automatic Context Checks: When this skill is invoked, immediately check:
| Source | Files/Folders | Search Terms | What to Extract |
| ----------------- | ---------------------------------------------- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| Metrics/Analytics | thoughts/shared/pm/metrics/*.md | "onboarding", "setup", "activation", D7, D30, "time to value", TTV | Current activation rates by stage, onboarding metrics, D7/D30 retention |
| User Research | thoughts/shared/pm/*.md | "onboarding", "setup", "first time", "confused", "stuck", "struggle" | User feedback on onboarding, confusion points, success moments |
| Meeting Notes | thoughts/shared/product/meeting-notes/*.md | "activation", "onboarding", "new users", "drop-off", "support tickets" | CS/support feedback on where users get stuck, win/loss reasons |
| PRDs | thoughts/shared/pm/prds/*.md | "onboarding", "activation", "tutorial", "first-time user" | Past onboarding improvements, features to drive activation |
| Business Info | thoughts/shared/pm/context/business-info-template.md | target user, customer segment, use case, primary value | Who you're activating, what value matters to them |
Context Priority:
Cross-Skill Links:
retention-analysisexpansion-strategyuser-research-synthesisBefore measuring the Setup → Aha → Habit stages, let me check what data already exists...
Checking:
thoughts/shared/pm/context/business-info-template.md for your product and target usersthoughts/shared/pm/metrics/ for existing activation metrics and onboarding datathoughts/shared/pm/ for user research on onboarding strugglesthoughts/shared/product/meeting-notes/ for CS/support feedback on where users get stuckthoughts/shared/pm/prds/ for past onboarding improvements[If analytics MCP connected]: "Let me also query [PostHog/PostHog] for your current activation funnel, setup completion rates, and D7/D30 retention by cohort."
Based on what I find, I'll show you:
From Business Info:
From Metrics/Analytics:
From User Research:
From Sales/CS Meetings:
From PRDs:
Based on internal context, we don't yet know:
Should I help define your three stages, or would you like to provide existing activation data first?
Instead of generic "what's your onboarding flow," I'll ask:
"Where do most new users drop off—in the first 5 minutes, or later in the week?"
This identifies whether the problem is setup friction, Aha not resonating, or habit formation.
"Among users who stuck around (D7+), what did they all do in their first session that churned users didn't?"
Your Aha must be defined by actual user behavior, not guesses.
"What specific actions should every new user complete in their first session to get value?"
This defines your Setup stage.
"How do you know a user 'got it'—what behavior indicates they experienced the core value?"
This is your Aha moment definition.
"What % of new signups complete your onboarding, and what % come back on Day 7?"
These baselines inform where to focus.
Activation is the bridge between signup and retention.
The Setup → Aha → Habit framework breaks activation into three measurable stages:
What it is: The initial configuration required before a user can experience value
Examples by product type:
Key principle: Setup should be the MINIMUM required to reach Aha
Metrics to track:
What it is: The moment when the user experiences your product's core value for the first time
How to find your Aha moment:
Examples by product:
Aha characteristics:
Metrics to track:
What it is: Recurring behavior pattern that cements long-term retention
Why it matters:
Examples by product:
Habit = Frequency + Value Pattern
Metrics to track:
Use this prompt pattern:
Use /activation-analysis and reference [[business-info-template]]
Help me define the Setup → Aha → Habit stages for my product.
Our product: [describe your product]
Core value proposition: [what value do users get]
Current onboarding flow: [describe existing flow]
For each stage, help me identify:
1. What actions constitute this stage?
2. What should we measure?
3. Where are users dropping off?
Calculate these metrics:
Setup Rate = (Users who complete setup) / (Total signups) × 100
Aha Rate = (Users who hit Aha) / (Users who complete setup) × 100
Habit Rate = (Users who form habit) / (Users who hit Aha) × 100
Overall Activation = Setup Rate × Aha Rate × Habit Rate
Example:
Where's the bottleneck? The biggest drop is your priority.
If Setup is low (<70%):
If Aha is low (<50%):
If Habit is low (<30%):
Use this prioritization:
Fix the biggest drop first
For Setup improvements:
For Aha improvements:
For Habit improvements:
TTV = Time from signup to Aha moment
Why it matters:
How to reduce TTV:
Eliminate unnecessary steps
Provide shortcuts
Progressive disclosure
Different paths for different users
Compare activation by cohort:
Use /activation-analysis
I have activation data for the past 3 months:
[paste your data or describe metrics]
Help me analyze:
1. Which cohorts have highest activation?
2. What changed between cohorts?
3. Where should we focus improvement efforts?
Look for:
Track these KPIs weekly:
| Metric | Definition | Target | Current | | -------------------- | ---------------------------- | ------- | ------- | | Signup → Setup | % who complete setup | 70%+ | ___ | | Setup → Aha | % who reach Aha moment | 50%+ | ___ | | Aha → Habit | % who form habit (D7 return) | 30%+ | ___ | | Overall Activation | Signup → Habit | 15%+ | ___ | | Time to Aha (median) | Minutes from signup to Aha | <10 min | ___ | | D7 Retention | % active on Day 7 | 40%+ | ___ | | D30 Retention | % active on Day 30 | 25%+ | ___ |
❌ Optimizing Aha without fixing Setup
❌ Defining Aha based on what you WANT users to do
❌ Ignoring Habit formation
❌ Same onboarding for all user types
❌ Measuring activation without connecting to retention
Use this with your team:
Research & Findings:
thoughts/shared/pm/analyses/activation-analysis-[date].mdOnboarding Improvements:
thoughts/shared/pm/prds/ for each onboarding changeActivation Metrics:
thoughts/shared/pm/metrics/ with your Setup, Aha, Habit definitions and ratesFeeds into:
/retention-analysis - Activation rate by stage informs retention analysis (Aha users retain better)/prd-draft - Onboarding improvements become features in PRDs/experiment-decision - Test setup flow changes or Aha moment triggers/metrics-framework - Define leading indicators (setup rate, Aha rate as early signals)Pulls from:
/user-research-synthesis - User feedback on onboarding struggles/retention-analysis - Understand habit formation patterns/competitor-analysis - How competitors handle onboarding/expansion-strategy - Activation enables expansion (activated users more likely to expand)After defining Setup → Aha → Habit, ask:
user-research-synthesis - Understand user struggles in onboarding, synthesis of feedbackexperiment-decision - Test activation improvements and measure impactretention-analysis - Measure habit formation (Aha → habit stage)prd-draft - Build features to improve activation based on this analysismetrics-framework - Define leading indicators of activation successexpansion-strategy - Activation enables expansion (prerequisite)define-north-star - Align activation metrics to North StarWhen delivering an activation analysis, use this consistent format:
# Activation Analysis: [Product/Feature Name]
**Date:** [Date]
**Analyst:** [PM Name]
---
## Executive Summary
[1-2 sentences: Current activation rate, biggest bottleneck, recommended action]
## Current Activation Funnel
| Stage | Definition | Rate | Benchmark | Gap |
| ---------------------- | -------------- | ----- | --------- | ------------------ |
| Signup → Setup | [actions] | \_\_% | 70%+ | [+/- vs benchmark] |
| Setup → Aha | [actions] | \_\_% | 50%+ | [+/- vs benchmark] |
| Aha → Habit | [actions] | \_\_% | 30%+ | [+/- vs benchmark] |
| **Overall Activation** | Signup → Habit | \_\_% | 15%+ | [+/- vs benchmark] |
**Time to Aha (median):** \_\_ minutes
**Biggest bottleneck:** [Stage with largest drop]
## Stage Definitions
- **Setup:** [Specific actions for your product]
- **Aha:** [Specific moment/action for your product]
- **Habit:** [Specific recurring behavior for your product]
## Bottleneck Diagnosis
[Root cause of biggest drop-off: friction, confusion, wrong users, missing value]
## Segment Differences
| Segment | Setup Rate | Aha Rate | Habit Rate | Insight |
| ----------- | ---------- | -------- | ---------- | --------- |
| [Segment 1] | \_\_% | \_\_% | \_\_% | [insight] |
| [Segment 2] | \_\_% | \_\_% | \_\_% | [insight] |
## Recommendations (Prioritized)
1. **[Fix 1]** - Expected impact: +\_\_% on [stage] rate
2. **[Fix 2]** - Expected impact: +\_\_% on [stage] rate
3. **[Fix 3]** - Expected impact: +\_\_% on [stage] rate
## Next Steps
- [ ] [Action 1] - Owner: [name] - Due: [date]
- [ ] [Action 2] - Owner: [name] - Due: [date]
Before delivering the activation analysis, verify:
Framework credit: Adapted from Aakash Gupta's activation frameworks. Read the full articles:
development
Migrate a single-harness repo to the dual-harness layout so both Claude Code and Codex load the same instructions and skills — AGENTS.md as the portable canonical doc, a thin CLAUDE.md `@AGENTS.md` bridge, and a `.agents/skills` dir with a `.claude/skills` symlink onto it. Use when asked to migrate to dual-harness, make this repo work in both Claude and Codex, or for agent metadata cleanup.
tools
Goal-driven senior-engineer pipeline-unstick sweep (CTL-1176 rung 3). Given the stuck/failed/needs-human set (or ONE ticket handed by the recovery router), its GOAL is to get the pipeline MOVING again — not to fix one ticket's review findings (that is phase-remediate). It runs AFTER the eyes (diagnostician evidence) and the hands (deterministic unstuck-sweep seams) have already tried, and it CONSUMES their output from a recovery-pass.json brief rather than re-diagnosing or redoing their narrow work. It acts like a senior engineer with full tool access — it resolves merge conflicts, rebases, force-pushes, merges green PRs, and re-dispatches stalled phases AUTONOMOUSLY — and escalates to the operator ONLY for a genuine value judgment / something that degrades other functionality / a real cost-benefit trade-off / a serious architecture change / an ADR conflict. On escalation it AUTHORS the operator inbox row + the push notification (executive-voiced). Dispatched as a `claude --bg` job by phase-agent-dispatch via slash command, AND invocable bare by the operator as a sweep — hence `user-invocable: true`. Ships behind CATALYST_RECOVERY_PASS (off by default — no live behavior change until shadow/enforce).
tools
Diagnose and fix Catalyst setup issues. Validates tools, database, config, OTel, direnv, and thoughts. Automatically fixes what it can — creates directories, initializes the database, sets WAL mode, runs migrations. Use for new installs, upgrades, or when something isn't working.
tools
--- name: phase-triage description: Phase agent that triages a Linear ticket — expands acronyms, classifies (feature/bug/docs/refactor/chore), identifies genuine blockers (a semantic second-pass over the backlog — NOT a prose scrape; CTL-838), estimates scope, writes triage.json, and posts a triage analysis comment to Linear. Triage completion is signaled by that comment plus the local triage.json — there is no `triaged` label. Emits phase.triage.complete.<TICKET> on success and phase.triage.fai