SkillCheck validator, Cursor exports, and per-agent installers (#27)
Three more learnings from alirezarezvani/claude-skills, applied: 1. SkillCheck validator (scripts/skillcheck.mjs) — validates every SKILL.md against the authoring standard (frontmatter, name/folder match, trigger + produces clauses, required headings) plus tier referential integrity. Errors fail CI; --strict fails on warnings too. New skillcheck.yml workflow and a SkillCheck status badge in the README. Current: 0 errors / 14 advisory warnings across 172 skills. 2. Cursor export platform — build-exports.mjs now generates exports/cursor/<bundle>/<skill>/<skill>.mdc rule files. The PLATFORMS registry now supports per-skill filenames (file as a function). 3. Per-agent installers — scripts/install.sh unifies install for claude/hermes/codex/openclaw/cursor (--link, --target, --dry-run, --list). Curl-able one-liners codex-install.sh, openclaw-install.sh, and cursor-install.sh clone the library and install in a single command. README documents the one-line installs and Cursor exports; CHANGELOG and the authoring standard updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
mohitagw15856
GitHub
@@ -0,0 +1,135 @@
|
||||
---
|
||||
description: "Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action."
|
||||
globs:
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# Data Analysis Standard Skill
|
||||
|
||||
Turn raw numbers into product decisions. Structure every analysis with a clear question, methodology, finding, and recommended action.
|
||||
|
||||
## Analysis Framework: The 4-Question Method
|
||||
|
||||
Every analysis starts here:
|
||||
1. **What changed?** (describe the metric and its movement)
|
||||
2. **Why did it change?** (root cause — segment, funnel step, cohort, channel)
|
||||
3. **So what?** (business or product impact)
|
||||
4. **Now what?** (recommended action with confidence level)
|
||||
|
||||
Never deliver data without answering all four. A chart with no narrative is not an analysis.
|
||||
|
||||
---
|
||||
|
||||
## Metric Triage Template
|
||||
|
||||
Use when a metric has moved unexpectedly:
|
||||
|
||||
```
|
||||
METRIC: [Name]
|
||||
MOVEMENT: [X% change over Y period]
|
||||
BASELINE: [What was normal]
|
||||
|
||||
SEGMENTATION CHECK:
|
||||
- By platform (iOS / Android / Web)?
|
||||
- By user cohort (new / returning / power users)?
|
||||
- By acquisition channel?
|
||||
- By geography?
|
||||
- By plan/tier?
|
||||
|
||||
ROOT CAUSE HYPOTHESIS:
|
||||
1. [Most likely explanation] — Evidence: [data point]
|
||||
2. [Alternative explanation] — Evidence: [data point]
|
||||
3. [Ruling out] — Eliminated because: [reason]
|
||||
|
||||
CONCLUSION: [Single sentence answer to "why did this change?"]
|
||||
CONFIDENCE: [High / Medium / Low] — based on [data available]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Funnel Analysis Structure
|
||||
|
||||
| Stage | Metric | Current | Benchmark/Target | Drop-off % | Notes |
|
||||
|---|---|---|---|---|---|
|
||||
| [Top of funnel] | [Users] | [N] | [N] | — | |
|
||||
| [Step 2] | [Users] | [N] | [N] | [X%] | |
|
||||
| [Step 3] | [Users] | [N] | [N] | [X%] | |
|
||||
| [Conversion] | [Users] | [N] | [N] | [X%] | |
|
||||
|
||||
**Biggest drop-off:** [Step X → Step Y] — Hypothesis: [reason]
|
||||
**Recommended investigation:** [specific query or test]
|
||||
|
||||
---
|
||||
|
||||
## Cohort Analysis Guidelines
|
||||
|
||||
Always define:
|
||||
- **Cohort definition:** [What groups users — signup week, first action, plan type]
|
||||
- **Retention metric:** [What counts as retained — login, core action, revenue]
|
||||
- **Retention window:** [D1, D7, D30, W4, M3, etc.]
|
||||
|
||||
Output a cohort retention table and annotate:
|
||||
- Baseline retention for each cohort
|
||||
- Cohorts that over/underperform and why (feature launch? campaign? seasonal?)
|
||||
- Trend direction across cohorts (improving / declining / stable)
|
||||
|
||||
---
|
||||
|
||||
## Stakeholder Analysis Output Format
|
||||
|
||||
### [Analysis Title] — [Date]
|
||||
|
||||
**Question being answered:** [Specific question in plain English]
|
||||
**Time period:** [Date range]
|
||||
**Data source:** [Where data comes from]
|
||||
|
||||
**Finding:**
|
||||
> [1–2 sentence plain-English summary of what the data shows]
|
||||
|
||||
**Key chart / table:** [Include or describe]
|
||||
|
||||
**Root cause:** [Best explanation with evidence]
|
||||
|
||||
**Confidence level:** [High / Medium / Low] — [reason]
|
||||
|
||||
**Recommended action:**
|
||||
1. [Immediate action — owner, timeline]
|
||||
2. [Investigation needed — what to check next]
|
||||
3. [Monitoring — what metric to watch and at what cadence]
|
||||
|
||||
**What this analysis does NOT tell us:** [Important caveat — what data is missing or what can't be concluded]
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Metric or question** being investigated
|
||||
- **Time period** (what changed, from when to when)
|
||||
- **Data available** (which segments, sources, or queries you have access to)
|
||||
- **Business context** (what decision this analysis informs)
|
||||
- **Audience** (who will read this — exec / team / data team)
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Analysis answers all 4 questions: what changed, why, so what, now what
|
||||
- [ ] Root cause has evidence (not just hypothesis)
|
||||
- [ ] Confidence level is stated and justified
|
||||
- [ ] What the data cannot tell us is explicitly named
|
||||
- [ ] Recommended action includes an owner and timeline
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not present correlations as causation — always state the distinction explicitly
|
||||
- [ ] Do not report a metric movement without stating the time window and comparison baseline
|
||||
- [ ] Do not skip the "so what" — raw observations without recommended actions are incomplete analysis
|
||||
- [ ] Do not overstate confidence — label hypotheses clearly and note what data would be needed to confirm them
|
||||
- [ ] Do not ignore segment breakdowns — aggregate metrics can mask opposing trends in sub-segments
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always state what the data *cannot* tell you — never oversell confidence
|
||||
- Correlations are not causation — flag this every time
|
||||
- If the user has no baseline, recommend establishing one before drawing conclusions
|
||||
- Recommend the simplest chart for each finding: bar for comparison, line for trends, scatter for correlation, table for detailed breakdowns
|
||||
- Always specify the time window — "conversion dropped" is meaningless without "from X to Y over Z period"
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
description: "Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions."
|
||||
globs:
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# Product Health Analysis Skill
|
||||
|
||||
Transform raw metrics data into a clear health narrative — what's working, what's not, and what needs immediate attention.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Metrics data** (current values for key metrics — even rough numbers work)
|
||||
- **Targets or benchmarks** (OKR targets, historical baselines, or industry benchmarks)
|
||||
- **Period** (week / month / quarter being analysed)
|
||||
- **Product area or segment** (are we looking at the whole product or a specific feature?)
|
||||
|
||||
## Metrics Framework
|
||||
Analyse across four layers:
|
||||
1. **Acquisition** — new users, source quality, CAC trends
|
||||
2. **Activation** — time to first value, onboarding completion rates
|
||||
3. **Engagement** — DAU/MAU, feature adoption, session depth
|
||||
4. **Retention** — D1/D7/D30 retention, churn rate, resurrection rate
|
||||
|
||||
## Process
|
||||
1. For each metric, compare: current period vs. previous period, current vs. target
|
||||
2. Flag anything more than 10% off target as requiring investigation
|
||||
3. Look for correlations — does a drop in activation explain a retention dip 2 weeks later?
|
||||
4. Write a plain-English health summary (no jargon) suitable for sharing with non-data stakeholders
|
||||
5. Recommend top 3 areas for immediate investigation with suggested diagnostic steps
|
||||
6. **Validate** — Confirm every flagged metric has a plausible root cause hypothesis, not just a raw number, and every recommended action has a specific owner or team
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Product Health Report — [Period]
|
||||
**Overall Health:** 🟢 On Track / 🟡 Watch / 🔴 Action Required
|
||||
|
||||
| Metric | Current | Target | vs. Last Period | Status |
|
||||
|--------|---------|--------|-----------------|--------|
|
||||
| [metric] | [value] | [target] | [+/-%] | [🟢/🟡/🔴] |
|
||||
|
||||
**Key Observations:**
|
||||
[3-5 bullet observations written in plain English]
|
||||
|
||||
**Areas Requiring Investigation:**
|
||||
1. [Metric + hypothesis + suggested diagnostic]
|
||||
2. [Metric + hypothesis + suggested diagnostic]
|
||||
3. [Metric + hypothesis + suggested diagnostic]
|
||||
|
||||
**Recommended Actions:**
|
||||
[Specific next steps with owners and timelines]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every metric includes both a target and a trend (not just a snapshot)
|
||||
- [ ] At least one correlation is drawn between metrics (e.g., activation → retention)
|
||||
- [ ] Every flagged metric has a root cause hypothesis, not just "it dropped"
|
||||
- [ ] Observations are written for a non-technical stakeholder (no raw query language or data jargon)
|
||||
- [ ] Overall health rating is justified with specific evidence
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not report a single aggregate metric without segment breakdowns — averages hide opposing trends
|
||||
- [ ] Do not flag a metric as healthy just because it is above the target — check if the target itself is meaningful
|
||||
- [ ] Do not list metric movements without root cause hypotheses — observations without explanations are not analysis
|
||||
- [ ] Do not mix product health metrics with business KPIs without explaining the relationship between them
|
||||
- [ ] Do not omit recommended actions — a health report that only describes problems without prioritised next steps is incomplete
|
||||
@@ -0,0 +1,143 @@
|
||||
---
|
||||
description: "Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions."
|
||||
globs:
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# Retention Analysis Skill
|
||||
|
||||
Diagnose why users leave, identify what keeps them, and recommend specific, testable interventions — not vague "improve onboarding" suggestions.
|
||||
|
||||
## Retention Fundamentals
|
||||
|
||||
**The retention curve has two components:**
|
||||
1. **Steepness of initial drop** (D1–D7) — onboarding problem
|
||||
2. **Long-term floor level** — product-market fit indicator
|
||||
|
||||
A product with PMF has a retention curve that flattens. If it trends to zero, you have a PMF problem, not an onboarding problem. Name this distinction explicitly.
|
||||
|
||||
---
|
||||
|
||||
## Retention Metrics Definitions
|
||||
|
||||
| Metric | Formula | What It Tells You |
|
||||
|---|---|---|
|
||||
| D1 Retention | Users who return on day 2 ÷ new users day 1 | Quality of first experience |
|
||||
| D7 Retention | Users active on day 8 ÷ users who joined 7 days ago | Early habit formation |
|
||||
| D30 Retention | Users active on day 31 ÷ users who joined 30 days ago | Product-market fit signal |
|
||||
| DAU/MAU Ratio | Daily active users ÷ monthly active users | Stickiness (>20% good, >50% excellent) |
|
||||
| Churn Rate | Users lost in period ÷ users at start of period | Monthly or annual |
|
||||
| Net Revenue Retention | MRR at end of period ÷ MRR at start (same cohort) | Revenue health including expansion |
|
||||
|
||||
---
|
||||
|
||||
## Retention Investigation Framework
|
||||
|
||||
### Step 1: Segment the problem
|
||||
Don't analyse "retention" — analyse retention for specific cohorts:
|
||||
- New vs returning users
|
||||
- Paid vs free
|
||||
- Acquisition channel (organic vs paid vs referral)
|
||||
- Onboarding path completed vs not
|
||||
- Feature usage (power users vs lurkers)
|
||||
|
||||
### Step 2: Find the inflection points
|
||||
Where does the drop happen? D1? D7? Month 3?
|
||||
- D1 drop → First session experience
|
||||
- D7 drop → Habit loop not formed
|
||||
- D30 drop → Value not delivered at depth
|
||||
- Month 3+ drop → Boredom, competition, or lifecycle event
|
||||
|
||||
### Step 3: Identify the "aha moment" correlation
|
||||
Which early behaviour predicts long-term retention?
|
||||
- Run correlation: users who did [X] in first 7 days vs 30-day retention
|
||||
- Common patterns: connected an integration, invited a teammate, completed a core action N times
|
||||
|
||||
### Step 4: Qualify the churn
|
||||
Interview churned users — never skip this. Survey data alone is insufficient.
|
||||
- "What was the trigger that led you to cancel/stop?"
|
||||
- "What were you trying to accomplish that you couldn't?"
|
||||
- "What would need to change for you to come back?"
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Retention Analysis — [Product/Segment] — [Date]
|
||||
|
||||
**Question:** [Specific retention question being answered]
|
||||
**Period Analysed:** [Date range]
|
||||
**Segment:** [Which users]
|
||||
|
||||
---
|
||||
|
||||
**Current Retention Snapshot:**
|
||||
|
||||
| Metric | Current | Industry Benchmark | Status |
|
||||
|---|---|---|---|
|
||||
| D1 Retention | [X%] | 25–40% | 🔴/🟡/🟢 |
|
||||
| D7 Retention | [X%] | 10–25% | 🔴/🟡/🟢 |
|
||||
| D30 Retention | [X%] | 5–15% | 🔴/🟡/🟢 |
|
||||
| DAU/MAU | [X%] | 10–20% typical | 🔴/🟡/🟢 |
|
||||
|
||||
**Retention Curve Shape:** [Flattening / Still declining / Trending to zero]
|
||||
**PMF Signal:** [Strong / Weak / Absent — based on curve shape]
|
||||
|
||||
---
|
||||
|
||||
**Root Cause Hypotheses:**
|
||||
|
||||
| Hypothesis | Evidence | Confidence | Test |
|
||||
|---|---|---|---|
|
||||
| [Cause] | [Data point] | H/M/L | [How to validate] |
|
||||
|
||||
**"Aha Moment" Correlation:**
|
||||
Users who [specific action] in first [N] days retain at [X%] vs [Y%] for those who don't.
|
||||
|
||||
---
|
||||
|
||||
**Recommended Interventions:**
|
||||
|
||||
| Intervention | Target Drop | Expected Lift | Effort | Priority |
|
||||
|---|---|---|---|---|
|
||||
| [Specific change] | D1 / D7 / D30 | [X%] | S/M/L | 1/2/3 |
|
||||
|
||||
**Monitoring Plan:**
|
||||
- Metric to track: [X]
|
||||
- Review cadence: [Weekly / Monthly]
|
||||
- Alert threshold: [If X drops below Y, investigate immediately]
|
||||
|
||||
---
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Product and business model** (SaaS / consumer app / marketplace / other)
|
||||
- **Current retention metrics** (D1, D7, D30 if available)
|
||||
- **Segment to analyse** (all users / paid / free / a specific cohort)
|
||||
- **Key question to answer** (why is retention dropping? what drives retention?)
|
||||
- **Available data** (analytics events, churn surveys, interview notes)
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Retention curve shape is diagnosed (flattening vs trending to zero = PMF vs onboarding)
|
||||
- [ ] Cohorts are segmented before analysis (not all users lumped together)
|
||||
- [ ] "Aha moment" correlation is identified or flagged as unknown
|
||||
- [ ] Interventions are specific (not "improve onboarding")
|
||||
- [ ] Churned user interviews are recommended (not just data analysis)
|
||||
- [ ] Monitoring plan includes an alert threshold
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not recommend "improve onboarding" without specifying what specific step to change and why
|
||||
- [ ] Do not analyse retention without segmenting by cohort — aggregate retention curves hide cohort-specific patterns
|
||||
- [ ] Do not treat DAU/MAU below 5% as a retention problem — at that level, it is a product-market fit problem
|
||||
- [ ] Do not skip qualitative research — churned user interviews reveal reasons that quantitative data cannot
|
||||
- [ ] Do not set a monitoring alert without specifying the threshold that triggers it
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never recommend "improve onboarding" without specifying *what* to change and *why*
|
||||
- Benchmark against industry — consumer apps, SaaS, and marketplaces have very different retention norms
|
||||
- If DAU/MAU is below 5%, that's a PMF conversation, not a retention tactics conversation
|
||||
- Always recommend talking to churned users — no amount of data replaces understanding the *reason*
|
||||
Reference in New Issue
Block a user