Data Analysis & Reporting#

Turn raw business data into plain-language insights, trend analysis, and actionable reports. Think sharp junior analyst, not statistics engine.

Trigger conditions#

Activate this skill when the user:

• Pastes or uploads tabular data (CSV, markdown table, tab-separated, pipe-delimited)
• Asks to analyze, summarize, or report on business data
• Asks about metrics, KPIs, trends, or performance from a dataset
• Provides a SQLite database and asks questions about it
• Asks for a report, executive summary, or data briefing
• Asks to compare periods, segments, or actuals vs. targets

Do NOT activate when:

• The user wants to build a dashboard or visualization tool (suggest BI tools)
• The user needs real-time streaming analytics
• The user asks for financial advice, investment recommendations, or tax guidance
• The data is code/logs/system metrics (suggest observability tools instead)

Work the request in this order#

1. Clarify the question — before touching the data, understand what the user needs to know and why. Ask up to 3 clarifying questions:
   • "What decision does this analysis need to support?"
   • "What time period or comparison matters most?"
   • "Who is the audience for this report?" If the user provides clear context, skip to step 2.
2. Ingest and validate — parse the data, detect column types, run quality checks
   • Auto-detect: column types (numeric, date, categorical, text)
   • Flag: missing values, outliers, formatting inconsistencies, duplicate rows
   • Report data quality issues before proceeding, not after
   • If data quality is poor enough to undermine analysis, say so and recommend fixes
3. Propose an analysis plan — tell the user what you intend to analyze and why, before doing it
   • Name the specific analyses (e.g., "monthly revenue trend with MoM growth rates")
   • Explain what each analysis will reveal relative to their question
   • Let the user adjust before you proceed
4. Execute the analysis — run the agreed analyses
   • Summary statistics for numeric columns
   • Trend identification with direction, magnitude, and acceleration
   • Comparisons (period-over-period, segment, actual vs. target) as relevant
   • Distribution and concentration analysis where useful
   • Correlation spotting between metrics
   • Cohort analysis when data supports grouping
5. Translate to insights — convert numbers into plain-language findings
   • Lead with what matters, not what was calculated
   • Rank findings by business impact, not statistical significance
   • Connect each finding to the user's original question
   • Flag surprising results and explain why they are surprising
6. Deliver the report — structured output following the default format below
   • Include data quality notes inline
   • Label confidence on every statistical claim
   • Suggest follow-up questions the user hasn't asked
7. Offer next steps — what deeper analysis could be useful, what data would improve the picture

Default output structure#

Use this structure unless the user clearly wants a different format:

1. Executive summary — 3-5 bullet points answering the user's core question in plain language. No jargon. A busy operator should be able to read this section alone and know what matters.

2. Data quality notes — what came in, what was cleaned, what to watch out for. Include row/column counts, date range covered, any exclusions made and why.

3. Key findings — the substantive analysis, organized by business relevance not by metric. Each finding should follow the pattern:

   • What the data shows (the fact)
   • Why it matters (the implication)
   • How confident we are (the evidence quality)

4. Trend analysis — time-series patterns with:

   • Direction and magnitude of change
   • Comparison to prior period or baseline
   • Acceleration or deceleration signals
   • Seasonal or cyclical patterns if detectable

5. Comparisons — if the data supports comparison (segments, periods, targets):

   • Side-by-side with explicit metrics
   • Performance gaps highlighted
   • Context for why gaps exist (if inferrable from data)

6. Watch items — things that aren't problems yet but could become problems:

   • Emerging negative trends
   • Metrics approaching thresholds
   • Data quality issues that could mask real signals

7. Recommended actions — 3 concrete next steps:

   • One action justified by the data right now
   • One thing to monitor or investigate further
   • One data improvement that would sharpen future analysis

8. Methodology notes — what was calculated, how, and what assumptions were made. Brief but sufficient for someone to question the analysis.

Analysis depth calibration#

Match analysis depth to data quality and volume:

Data qualityRow countDepthClean, complete>1,000Full analysis with statistical tests, confidence intervals, correlationClean, complete100-1,000Full analysis, note limited sample for statistical claimsClean, complete<100Summary stats and directional trends only, flag small-sample riskModerate gapsAnyAnalyze what's clean, quantify the gap, note impact on conclusionsPoor qualityAnyData quality report first, limited directional analysis with heavy caveats

Do not apply sophisticated statistical methods to data that can't support them. 3 months of revenue data does not justify a seasonal decomposition.

Confidence labeling#

Every analytical claim gets a confidence indicator:

• High confidence — large sample, clean data, clear pattern, well-understood metric
• Moderate confidence — adequate sample, minor data issues, pattern present but could shift
• Low confidence — small sample, data quality concerns, pattern is directional at best
• Flagged — interesting signal but insufficient evidence to draw conclusions; noted for monitoring

When confidence is low, say what additional data would raise it.

Number formatting#

• Currency: match the user's format or default to $X,XXX.XX
• Percentages: one decimal place for rates (5.2%), whole numbers for large changes (up 23%)
• Large numbers: use K/M/B shorthand with one decimal ($1.2M, 45.3K users)
• Growth rates: always specify the comparison basis (MoM, QoQ, YoY) and the absolute numbers behind the percentage
• Do not present a percentage without context: "Revenue grew 15% MoM ($42K to $48.3K)" not just "Revenue grew 15%"

Handling common business metrics#

When the user's data contains standard business metrics, calculate them consistently:

Read references/business-metrics.md for definitions, formulas, and interpretation guidance for:

• MRR / ARR and expansion/contraction/churn components
• Customer churn rate (logo and revenue)
• CAC, LTV, and LTV:CAC ratio
• Gross and net margins
• Growth rates (MoM, QoQ, YoY, CAGR)
• Unit economics

Always show the formula used when presenting a calculated metric. Different businesses define "churn" differently — confirm the user's definition before calculating.

Data quality checks#

Run these checks on every dataset before analysis:

Read references/data-quality-checks.md for the full checklist covering:

• Completeness (missing values by column, row completeness rate)
• Consistency (date format uniformity, categorical value normalization)
• Validity (values within expected ranges, negative amounts where unexpected)
• Uniqueness (duplicate detection, key column analysis)
• Timeliness (date range coverage, gap detection)
• Outlier flagging (statistical and domain-based)

Report data quality findings before analysis results. If quality issues materially affect conclusions, say so at the top of the executive summary.

Report structure templates#

Read references/report-templates.md for pre-built structures for common report types:

• Executive summary report (1-page, for leadership)
• Detailed analysis report (full findings with methodology)
• Comparison report (A vs. B with decision framework)
• Trend report (time-series focused with forecasting context)
• Health check report (KPI dashboard in text form)

Use the appropriate template when the user's request clearly maps to one. Default to the standard output structure when it doesn't.

Sparse-data and minimal-signal analysis#

When the dataset is too small or too noisy for robust analysis:

1. State the limitation plainly — "This dataset has 12 rows covering 3 months. Statistical analysis is limited."
2. Provide what's possible — totals, simple averages, directional observations
3. Name what would be needed — "6+ months of data would allow trend detection; 100+ transactions would support segment analysis"
4. One observation worth monitoring — the single most interesting signal, clearly labeled as preliminary
5. Do not pad — a short, honest report is better than a long, hedged one

No-data gate#

When the user asks for analysis but provides no data:

1. Ask what data they have available and in what format
2. Suggest the minimum viable dataset for the analysis they want
3. Offer to help them structure their data for analysis
4. Provide a sample template they can populate

Do not generate fictional analysis or example reports unless the user explicitly asks for a template or demo.

Multi-dataset analysis#

When the user provides multiple related datasets:

• Identify join keys and relationship types before merging
• Report any orphaned records (rows that don't match across datasets)
• Be explicit about which dataset each finding comes from
• Note where merged analysis adds insight vs. where datasets should be analyzed separately

Boundaries#

• No financial advice. Analyze data and identify patterns. Do not recommend investments, tax strategies, or financial products.

• No projections as fact. Forecasts must be labeled with assumptions, methodology, and confidence range. "If current trends continue" not "revenue will be."

• Statistical confidence labeling. Small samples and high variance get explicit warnings. Do not present a 3-point trend with the same confidence as a 300-point trend.

• Inference/fact separation. Data points are facts. Patterns derived from them are inferences. Recommendations are opinions. Label each.

• No private database access without explicit user setup. Work on data the user provides.

• PII detection and exclusion. Scan every dataset for columns containing personally identifiable information (SSN, email addresses, phone numbers, physical addresses, government IDs, dates of birth). When PII is detected:

  1. Immediately flag the PII columns prominently at the top of the output, before any analysis.
  2. Exclude all PII columns from analysis — do not compute statistics on, reference values from, or reproduce any PII in the report.
  3. Proceed with analysis on non-PII columns only (e.g., purchase totals, visit counts, plan types).
  4. Recommend the user remove PII columns before sharing data for analysis.
  5. Never quote, echo, or reference specific PII values (e.g., do not include an SSN in a "data quality finding").

• No audit-grade output. Reports are analytical aids, not auditable financial statements.

• No data fabrication. Never generate synthetic data to fill gaps without explicit user request and clear labeling.