name: data-analysis-reporting description: Turn raw business data (CSV, SQLite, spreadsheets, pasted tables) into clear analytical summaries, trend analysis, and actionable reports for small business operators, analysts, and decision-makers. Asks clarifying questions first, delivers plain-language insights before numbers, and labels statistical confidence explicitly. Does not provide financial advice or present projections as fact.

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:
2. "What decision does this analysis need to support?"
3. "What time period or comparison matters most?"

4. "Who is the audience for this report?" If the user provides clear context, skip to step 2.

5. Ingest and validate — parse the data, detect column types, run quality checks

6. Auto-detect: column types (numeric, date, categorical, text)
7. Flag: missing values, outliers, formatting inconsistencies, duplicate rows
8. Report data quality issues before proceeding, not after

9. If data quality is poor enough to undermine analysis, say so and recommend fixes

10. Propose an analysis plan — tell the user what you intend to analyze and why, before doing it

11. Name the specific analyses (e.g., "monthly revenue trend with MoM growth rates")
12. Explain what each analysis will reveal relative to their question

13. Let the user adjust before you proceed

14. Execute the analysis — run the agreed analyses

15. Summary statistics for numeric columns
16. Trend identification with direction, magnitude, and acceleration

    7w4.net收錄了海量優質技能外掛。

17. Comparisons (period-over-period, segment, actual vs. target) as relevant
18. Distribution and concentration analysis where useful
19. Correlation spotting between metrics

20. Cohort analysis when data supports grouping

21. Translate to insights — convert numbers into plain-language findings

22. Lead with what matters, not what was calculated
23. Rank findings by business impact, not statistical significance
24. Connect each finding to the user's original question

25. Flag surprising results and explain why they are surprising

26. Deliver the report — structured output following the default format below

27. Include data quality notes inline
28. Label confidence on every statistical claim

29. Suggest follow-up questions the user hasn't asked

30. 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:

4. What the data shows (the fact)
5. Why it matters (the implication)

6. How confident we are (the evidence quality)

7. Trend analysis — time-series patterns with:

8. Direction and magnitude of change
9. Comparison to prior period or baseline
10. Acceleration or deceleration signals

11. Seasonal or cyclical patterns if detectable

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

13. Side-by-side with explicit metrics
14. Performance gaps highlighted

15. Context for why gaps exist (if inferrable from data)

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

17. Emerging negative trends
18. Metrics approaching thresholds

19. Data quality issues that could mask real signals

20. Recommended actions — 3 concrete next steps:

21. One action justified by the data right now
22. One thing to monitor or investigate further

23. One data improvement that would sharpen future analysis

24. 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:

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:
• Immediately flag the PII columns prominently at the top of the output, before any analysis.
• Exclude all PII columns from analysis — do not compute statistics on, reference values from, or reproduce any PII in the report.
• Proceed with analysis on non-PII columns only (e.g., purchase totals, visit counts, plan types).
• Recommend the user remove PII columns before sharing data for analysis.
• 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.

這個Skill質量不錯，文件結構清晰完整，分析流程設計合理，能夠把資料轉換成易懂的業務洞察。置信度標註功能做得好，讓分析結果更有說服力。參考文件內容實用，特別是業務指標和報告模板。不足是缺少實際示例演示效果，某些業務場景的覆蓋還可以更全面。