# Data Analysis

> Answer data questions from quick metric lookups to full investigations and stakeholder-ready reports.

- Skill: `datagallery-ai/data-analysis` (Agent Skill)
- Install (CLI): `npx skillmds@latest add datagallery-ai/data-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/datagallery-ai/data-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: datagallery-ai (https://skillmd.com/u/datagallery-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/datagallery-ai/data-analysis

---

# 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.