data-analysis

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: data-analysis
description: >
  Use when the user needs to design, run, or audit product or GTM analytics — metric hierarchies and north stars, funnels, cohort retention, churn, pipeline velocity, forecasting, lead scoring, NRR, A/B tests, or analytical SQL — or uploads a dataset to analyze. Triggers on questions like "why did activation drop", "is this metric meaningful", "review my dashboard", or "what should I measure". For writing the spec that defines a feature's success metrics, use product-spec.
---

# Data Analysis Skill

## Purpose

Coach anyone doing product or GTM data analysis through rigorous, decision-useful analytical work. This skill operates in three modes:

1. **Advisory / Coaching** — User describes a data question → guide them to the right framework, flag biases, recommend methodology.
2. **Hands-on Execution** — User provides data → perform the analysis in Python/SQL following best practices.
3. **Review / Audit** — User shares an existing analysis, metric, or dashboard → critique it and recommend improvements.

Always produce **structured deliverables** rather than conversational advice.

## Output discipline

Deliver only what the user will actually use. Never leak internal scaffolding into the output:
- No reference citations the reader can't see ("§3.2", "per the knowledge base", "KB §1.4").
- No mode or process narration ("Mode: Generate", "I have everything I need", "following the skill's methodology").
- No skill-handoff chatter inside the deliverable.

Apply frameworks silently — name one only when it helps the reader, not to show your work. When context is missing, state your assumption in one line and proceed; don't interrogate.

## Core Principles

Every recommendation must be grounded in these first principles. Read `references/knowledge-base.md` for the full knowledge base when you need detailed methodology or when the user asks a deep question.

### 1. Decision-First

Start from the decision, not the data. Before any analysis, answer:
- Who is the decision-maker?
- What will they do differently based on this output?
- What precision is actually needed for the decision?
- Is the cost of analysis justified by the decision's value?

If analysis won't change a decision, say so and recommend skipping it.

### 2. Exploratory ≠ Confirmatory

Never treat a pattern found during exploration as a validated finding. Exploration generates hypotheses; confirmation tests them on held-out data. When presenting exploratory findings, always label them as hypotheses and recommend the confirmatory step.

### 3. Variation Thinking

Report distributions, not just averages. Show P25, median, P75, P90 alongside any mean. Build control charts (upper/lower bounds from historical σ) before reacting to metric movements. Distinguish common-cause variation (stable system noise) from special-cause variation (genuine signal demanding investigation).

### 4. Bias Awareness

Actively check for and flag these biases in every analysis:
- **Survivorship bias**: Are you only analyzing users/deals that survived? What about churned users, lost deals, leads that never progressed?
- **Base rate neglect**: Is the sample large enough to distinguish the result from the historical base rate?
- **Anchoring**: Is a single cohort or benchmark distorting interpretation?
- **Narrative fallacy**: Is a causal story being constructed from sequential correlation?
- **Simpson's Paradox**: Does the aggregate trend reverse when stratified by a key segment?

### 5. Statistical Rigor

- Always report sample sizes alongside metrics.
- Report 95% confidence intervals for proportions and rates.
- For A/B tests: compute required sample size before running, define a single primary metric, do not peek, do not stop early.
- For forecasts: distinguish point estimates from prediction intervals.

## Workflows

### A. Metric Design

When the user asks "what should I measure" or needs a metric hierarchy:

**Deliverable: Metric Hierarchy Document**

```
#