data-analysis

name	data-analysis
description	Answer data questions from quick metric lookups to full investigations and stakeholder-ready reports.
version	1.0.0
tags	["data","analysis","sql","report","数据分析","查数","指标"]
allowed-tools	["list_data_sources","inspect_schema","preview_table","run_sql_readonly","retrieve_knowledge","read_file","write_file","list_files"]
denied-tools	[]
user-invocable	true

Data Analysis

Use this skill for natural-language data questions, including metric lookups, trend investigations, segment comparisons, anomaly checks, quality reviews, and short reports.

Chinese search aliases: 数据分析, 查数, 指标查询, 报表, SQL 分析, 趋势分析, 维度, 度量, 异常检查, 数据质量.

This workflow is adapted for this workbench from public data-analysis skill patterns:

• Classify the user's request before querying.
• When a knowledge base is enabled for the run, call retrieve_knowledge first for definitions, prior findings, or document-backed facts before guessing or writing SQL.
• Explore schema before SQL.
• Retrieve only the data needed for the current question.
• Validate results before presenting them.
• Match the output to the user's requested level of detail.

Workflow

1. Understand The Question

Classify the task:

• Quick answer: one metric, a simple filter, or a factual lookup.
• Full analysis: trends, drivers, comparisons, segmentation, or anomalies.
• Report: a structured write-up with method, findings, caveats, and recommendations.

Identify the needed datasource, tables, metrics, dimensions, filters, time range, and output format. If a required business definition is missing, state the assumption or ask only when guessing would materially change the answer.

2. Explore Before Querying

Always inspect the relevant datasource before writing SQL unless a valid schema token is already available in the current run.

Use progressive disclosure:

• Start broad with datasource and schema discovery.
• Narrow to candidate tables and columns.
• Inspect only the specific tables needed for the query.
• Use preview_table sparingly to understand shape, examples, nulls, or category values.

Do not dump broad schemas into the answer. Keep schema exploration focused on the user's task.

3. Query Read-Only Data

Write precise SELECT or WITH SQL through run_sql_readonly.

Use exact inspected table and column names. If a query fails, inspect the schema or simplify the query before retrying. Do not guess alternate names blindly.

For multi-step analysis, break the problem into focused sub-questions. Prefer a small number of high-signal queries over many speculative queries.

4. Validate Results

Before presenting conclusions, perform checks appropriate to the task:

• Row count sanity: does the result size make sense?
• Null handling: could missing values skew the result?
• Magnitude check: are values in a plausible range?
• Aggregation check: do subtotals align with totals?
• Trend continuity: are there unexpected gaps or date boundary issues?
• Filter check: did the query apply the user's requested scope?

If validation raises concerns, investigate when possible and surface the caveat.

5. Present The Answer

For quick answers:

• Lead with the direct answer.
• Include the most relevant context or caveat.
• Include SQL only when it helps reproducibility.

For full analyses:

• Lead with the key finding.
• Support it with compact tables, calculations, or charts when useful.
• Explain method and caveats.
• Suggest the next best follow-up only when it is actionable.

For reports:

• Write a concise executive summary.
• Include method, findings, evidence, caveats, and recommendations.
• Save longer reports or reusable outputs as workspace files and publish them as artifacts.

Guardrails

• Never invent schemas, rows, metric definitions, SQL results, or file contents.
• Never use write SQL, DDL, multi-statement SQL, or direct database clients.
• Never bypass the Data Gateway with command-line database clients.
• Never hide tool failures; explain what failed and how you adapted.
• Keep conclusions proportional to the data actually inspected.