data-analysis

name

data-analysis

description

Fetch, query, and analyze project data. Use this skill when the user wants to investigate metrics, understand user behavior, debug a data issue, or answer a question that requires looking at real data. Triggers on "what happened", "why did X drop", "show me the numbers", "query", "metrics", "funnel", "cohort", "data", "analytics", "dashboard", "events", "logs". Even if the user just asks "what happened on Tuesday", use this skill — it has the query patterns and data sources to find out.

Data Analysis

You answer data questions by fetching real data, not guessing. This skill gives you the tools and query patterns to investigate.

Read config.json in this skill directory for data source configuration. If it doesn't exist, ask the user to set it up (see Setup section).

Data sources

Check scripts/ for helper functions specific to this project. These scripts encode domain knowledge (which tables to join, which event names to use, how to dedupe) so you don't have to figure it out each time.

If helper scripts exist, compose them — import and combine rather than rewriting from scratch. Generate new investigation scripts on the fly that use the helpers. Save useful investigation scripts in scripts/ for reuse.

If no helpers exist yet, write the query directly, then extract reusable parts into helpers for next time.

Common investigation patterns

Adapt these to the project's actual data stack:

"What happened on [date]?" — Compare the target day against the previous day and same day last week. Look at volume, error rate, and key conversion points.

"Why did [metric] drop?" — Segment by the obvious dimensions first (source, device, geography, plan tier). The segment where the drop is concentrated tells you where to dig.

"Is [thing] working?" — Define "working" as a measurable assertion. Query the data, check the assertion, report the result.

"Compare A vs B" — Pull the same metrics for both cohorts. Flag differences that exceed normal variance. Note sample sizes.

How to query

Use whatever the project provides — adapt to the stack:

• SQL databases: Write queries directly or use helper scripts
• AWS CloudWatch: Use aws cloudwatch get-metric-statistics
• DynamoDB: Use aws dynamodb query with appropriate key conditions
• Event systems: Use the project's event query library
• Logs: Use aws logs filter-log-events or grep on log files
• Third-party APIs: Stripe dashboard data, Discord analytics, etc.

Always show your work: the query you ran, the raw numbers, then your interpretation. Don't just state conclusions.

Output

# Data Analysis — [question or topic]

## Question
[What we're trying to answer]

## Method
[Data source, query approach, time range]

## Findings
[Key numbers, with context and comparison]

## Interpretation
[What the data means — not what it says, but what it implies]

## Next steps
[Further investigation if needed, or action items]

Setup

Create config.json in this skill directory:

{
  "data_stack": "postgres|dynamodb|cloudwatch|custom",
  "primary_db": {
    "type": "dynamodb",
    "region": "us-east-1",
    "tables": ["users", "events", "billing"]
  },
  "key_metrics": [
    "daily_active_users",
    "signup_to_activation_rate",
    "revenue"
  ],
  "event_names": {
    "signup": "signup_completed",
    "activation": "first_action_completed",
    "upgrade": "checkout_completed"
  }
}

Gotchas

• Use event names from config, not guesses. "signup_completed" and "signup_started" are very different numbers.
• Always dedupe before counting. The same event can fire multiple times.
• Show raw numbers AND percentages. "50% drop" on 4 events is noise, on 4000 it's a crisis.
• Time zones matter. Specify UTC or local in every query.
• Don't just state what changed — explain what it means for the business.

Memory

Append each investigation to ${CLAUDE_PLUGIN_DATA}/investigations.log if available, otherwise to tasks/data-investigations.log:

[YYYY-MM-DD] Q: [question] → A: [one-line finding]

This log helps spot recurring questions and build better dashboards.