plugins/pm/skills/metrics-framework/SKILL.md
Set up leading vs lagging indicators for product decisions. Framework for metric selection and tracking.
npx skillsauth add coalesce-labs/catalyst metrics-frameworkInstall 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.
When to use: Setting up metrics, designing dashboards, or when you need early signal before outcomes materialize
Framework source: Aakash Gupta's "Become an A/B Testing Expert" and metrics guidance
thoughts/shared/pm/frameworks/ for your North Star and thoughts/shared/pm/metrics/ for baseline datathoughts/shared/pm/metrics/metrics-framework-[date].mdKey principle: Leading metrics should PREDICT lagging metrics. If they do not, you are tracking the wrong thing. We always validate the correlation before committing to a leading indicator.
Automatic Context Checks: When this skill is invoked, immediately check:
| Source | Files/Folders | Search Terms | What to Extract |
| ---------------- | ---------------------------------------------- | ------------------------------------ | -------------------------------------- |
| Strategy Context | thoughts/shared/pm/frameworks/*.md | North Star, objective, business goal | Company-wide lagging metric target |
| Business Model | thoughts/shared/pm/context/business-info-template.md | metrics, KPIs, growth model | Current revenue/retention/growth focus |
| Metrics History | thoughts/shared/pm/metrics/*.md | baseline, trends, benchmarks | Historical leading/lagging metric data |
| PRDs | thoughts/shared/pm/prds/*.md | success metrics, measurement | Feature-level metric definitions |
| Meetings | thoughts/shared/product/meeting-notes/*.md | "metrics", "dashboard", "KPI" | Stakeholder metric priorities |
Context Priority:
Cross-Skill Links:
/define-north-star/feature-metrics for STEDII framework/retention-analysis and /activation-analysis/feature-resultsBefore designing your metrics framework, let me understand what you're optimizing for...
Checking:
thoughts/shared/pm/context/business-info-template.md for business model and goalsthoughts/shared/pm/frameworks/*.md for strategic prioritiesthoughts/shared/pm/metrics/ for existing metric baselinesthoughts/shared/pm/prds/ for current feature success metricsBased on what I find, I'll show you:
North Star / Lagging Metric:
Existing Leading Indicators:
Metric Gaps:
Definition: Metrics that measure final outcomes - what already happened
Characteristics:
Examples:
When to use:
Definition: Metrics that predict future outcomes - early signals
Characteristics:
Examples:
When to use:
Leading metrics should PREDICT lagging metrics.
If they don't, you're tracking the wrong leading metrics.
Lagging: Monthly revenue Leading:
Logic: If add-to-cart drops today, revenue drops next week.
Lagging: 90-day retention Leading:
Logic: Users who activate in 7 days have 10x better 90-day retention.
Lagging: GMV (Gross Merchandise Value) Leading:
Logic: More searches + better inventory = more transactions = higher GMV
What's the ultimate outcome you care about?
Examples:
Use this prompt pattern:
Use /metrics-framework and reference thoughts/shared/pm/context/business-info-template.md
Our North Star / main outcome metric is: [your lagging metric]
Help me identify 3-5 leading indicators that:
1. Happen BEFORE this outcome
2. Predict this outcome with data
3. Are actionable (we can influence them)
4. Give us signal within 1-2 weeks
Our product: [describe product]
User journey: [describe key actions]
Current metrics: [what you track today]
Run analysis to prove the connection:
Cohort analysis:
Time-series correlation:
If no correlation exists, it's not a leading indicator.
Before trusting any correlation between leading and lagging metrics:
Minimum thresholds:
Data quality red flags:
How to communicate data quality:
Build a metric tree from lagging → leading:
LAGGING (Outcome)
↑
LEADING (Predictive)
↑
INPUT METRICS (Drivers)
Tier 1 - Lagging (Annual):
Tier 2 - Leading (Monthly):
Tier 3 - Input Metrics (Weekly):
Tier 4 - Activation Metrics (Daily):
How it works:
Problem: Most dashboards show only lagging metrics
Solution: Split your dashboard into sections:
North Star:
Leading Indicators:
Input Metrics:
Lagging: Subscriber growth, Revenue Leading:
Why it works: High engagement predicts low churn predicts revenue growth
Lagging: Nights booked (GMV) Leading:
Why it works: More supply + faster responses = more bookings
Lagging: Premium subscriber growth Leading:
Why it works: Highly engaged free users convert to paid
Chain:
Application: Focus on activation to drive long-term revenue
Chain:
Application: Drive engagement before asking for money
Chain:
Application: Build quality product → users refer friends
Problem: Your "leading" metric moves, but lagging metric doesn't
Example:
Fix: Find a different leading metric with proven correlation
Problem: Your leading metric takes 6 months to show signal
Example:
Fix: Find faster signals (weekly, not quarterly)
Problem: Metric looks good but doesn't predict anything
Examples:
Fix: Validate with cohort analysis
Question: Should we build Feature X?
Bad answer: "It might increase revenue" Good answer: "It will increase [leading metric] by X%, which historically drives [lagging metric] by Y%"
Question: Should we run an A/B test for 4 weeks?
Bad answer: "We need to measure revenue impact" Good answer: "We can measure activation rate in Week 1, which predicts retention in Month 1"
Bad goal: "Increase revenue 20%" Good goal: "Increase activation rate from 45% → 60%, which drives revenue +20%"
Why better: Team can influence activation daily, can't directly influence revenue
Use this for any metric you're considering:
Leading Metric Criteria:
Lagging Metric Criteria:
"What's the ultimate outcome?" → Answer: Customer lifetime value (LTV)
"What predicts LTV?" → Analysis shows: 90-day retention predicts LTV → Leading metric: 90-day retention rate
"What predicts 90-day retention?" → Analysis shows: Day 7 activation predicts 90-day retention → Leading metric: Day 7 activation rate
"What drives Day 7 activation?" → Analysis shows:
❌ Only tracking lagging metrics
❌ Claiming correlation without data
❌ Too many leading metrics
❌ Optimizing leading metrics that don't matter
North Star: [Metric] Framework Type: [Leading/Lagging Hierarchy or Input/Output Model]
| Tier | Metric | Current | Target | Cadence | Owner | | ------------------- | ----------------------------------------------- | ---------- | ------ | ---------------- | -------------- | | Lagging (Quarterly) | [e.g., Revenue, LTV, 90-day retention] | [Baseline] | [Goal] | Quarterly review | [Executive/PM] | | Leading (Weekly) | [e.g., Day 7 activation, WAU, feature adoption] | [Baseline] | [Goal] | Weekly review | [PM/Growth] | | Leading (Weekly) | [e.g., Time to first value, invite rate] | [Baseline] | [Goal] | Weekly review | [PM/Growth] | | Input (Daily) | [e.g., Signups, setup completion, first action] | [Baseline] | [Goal] | Daily monitoring | [Team lead] | | Input (Daily) | [e.g., Support tickets, error rate] | [Baseline] | [Goal] | Daily monitoring | [Engineering] |
| Hypothesis | Test Method | Data Needed | Timeline | | ---------------------------------------------- | ------------------------------------------------------------ | --------------------------- | ------------------- | | [Leading metric X] predicts [Lagging metric Y] | Cohort analysis: compare high-X vs low-X users on Y outcome | 3 months of user-level data | 2 weeks to validate | | [Input metric A] drives [Leading metric B] | Time-series correlation: does A movement precede B movement? | 6 weeks of daily data | 1 week to validate |
| Metric | Green (On Track) | Yellow (Attention) | Red (Intervention) | Action on Red | | ---------------- | ---------------- | --------------------------------- | --------------------------- | --------------------------------------------------------------------- | | [Lagging metric] | [Above target] | [Within 1 SD or 10% below target] | [2 SD or 20%+ below target] | [Who gets alerted; what investigation to run; what corrective action] | | [Leading metric] | [Above target] | [Within 1 SD or 10% below target] | [2 SD or 20%+ below target] | [Who gets alerted; what investigation to run; what corrective action] | | [Input metric] | [Above target] | [Within 1 SD or 10% below target] | [2 SD or 20%+ below target] | [Who gets alerted; what investigation to run; what corrective action] |
Section 1 - North Star (top of dashboard): [The ONE lagging metric, shown as a large number with monthly/quarterly trend line and target overlay]
Section 2 - Leading Indicators (middle): [3-5 weekly metrics shown as sparkline charts with alert thresholds marked. Each metric includes a comparison to prior week and target.]
Section 3 - Input Metrics (bottom): [5-10 daily levers shown as a table with current value, WoW change, and status indicator (green/yellow/red). Grouped by team ownership.]
For each key metric, define three thresholds:
For each Red threshold, specify three things:
Calibration tip: Start with thresholds based on historical variance. After 4-6 weeks, adjust based on actual alert volume. If you get Yellow alerts every week, your threshold is too sensitive. If you never get Yellow alerts, it is too loose.
Leading indicators don't last forever. Retire or replace them when:
Signals it's time to retire a metric:
Retirement process:
Common retirement patterns:
For products with multiple value streams (e.g., separate features for creation, analytics, and collaboration), do not try to force everything into one flat metric hierarchy. Instead:
Metric framework documentation:
thoughts/shared/pm/metrics/metrics-framework-[date].md (living document for your team)After building your framework:
Feeds into:
/define-north-star - Your lagging metric becomes (or informs) the North Star/feature-metrics - Feature success metrics are leading indicators in this framework/retention-analysis - Leading metrics for retention are identified here/activation-analysis - Activation metrics are leading indicators for engagementPulls from:
/write-prod-strategy - Strategy determines what you're optimizing forthoughts/shared/pm/metrics/ - Historical data validates correlations/define-north-star - What is your ultimate success metric?/define-north-star - Choose your North Star (lagging metric)/activation-analysis - Find leading activation indicators/feature-metrics - Choose experiment metrics with STEDII/retention-analysis - Analyze retention predictorsBefore delivering the metrics framework, verify:
/define-north-star first.Framework credit: Adapted from Aakash Gupta's metrics frameworks. Read: https://www.news.aakashg.com/p/become-an-ab-testing-expert-advanced
testing
Phase-agent that fixes a failing verify verdict so the pipeline self-heals instead of stalling to needs-human (CTL-653). Reads `${ORCH_DIR}/workers/<ticket>/verify.json`, fixes the `findings[]` (every severity:"high" plus the regression_risk drivers) directly via Edit/Write, commits the remediation, and emits `phase.remediate.complete.<ticket>`. The scheduler's router then re-dispatches `verify` to re-check (the verify⇄remediate cycle, cap 3). Dispatched as a `claude --bg` job by `phase-agent-dispatch`, which invokes it via slash command — hence `user-invocable: true`.
development
Phase agent for the verify step of the 9-phase orchestrator pipeline (CTL-450). NEW skill — has no canonical wrapper. Runs read-only adversarial verification against the implement-phase diff: tsc, tests, lint, security scan, reward-hacking scan, code review, test coverage, silent-failure hunt. Writes ${ORCH_DIR}/workers/<TICKET>/verify.json then emits phase.verify.complete.<ticket>. Reads phase-implement.json as its prior-phase artifact. NEVER writes application code — only test files allowed. Spawned via phase-agent-dispatch via slash command — hence `user-invocable: true`.
tools
--- name: phase-triage description: Phase agent that triages a Linear ticket — expands acronyms, classifies (feature/bug/docs/refactor/chore), identifies dependencies, 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.failed.<TICKET> on error. Dispatched by the phase-agent orchestrator (CTL-452)
testing
Phase agent for the review step of the 9-phase orchestrator pipeline (CTL-450). Wraps the /review skill (gstack) — explicitly skips /ultrareview per user decision. Reads verify.json from the prior phase, runs /review against the diff, writes ${ORCH_DIR}/workers/<TICKET>/review.json, and creates a remediation commit for any HIGH-severity finding that has a deterministic fix. Emits phase.review.complete.<ticket>. Spawned via phase-agent-dispatch via slash command — hence `user-invocable: true`.