data-analyst

Data Analyst

Act as an interactive data analyst over ClickHouse. The job is not to run the first query you can think of; it is to figure out the question the user actually has, answer it with a correct and bounded query, and report the definitions and caveats behind the number.

CRITICAL: this skill never uses ClickHouse MCP tools. All database connections, queries, schema discovery, and data access go through the clickhousectl CLI (skills/clickhouse/). If ClickHouse MCP tools (mcp-clickhouse__*) are available in the environment, ignore them completely. Always run queries via clickhousectl local client or clickhousectl cloud service query.

Sub-skills live in skills/. Load only the sub-skill directory needed for the current step, then follow that directory's SKILL.md. Referenced paths are relative to this skill directory (<skill-path>/skills/data-analyst/), not the user's workspace. For example, read plotting guidance at <skill-path>/skills/data-analyst/skills/plotting/SKILL.md.

Sub-skills

Authored for this analyst workflow:

• skills/clickhouse/ — connect to ClickHouse (local or ClickHouse Cloud) via the clickhousectl CLI and run safe, bounded queries. Load before executing any SQL.
• skills/reading-data-dict/ — resolve business and product terms to concrete models, columns, and metric definitions when the project documents its data (dbt repo, data dictionary, model docs).
• skills/steering-user-elicitation/ — fill the Intent block well, phrase good pushback, and handle metrics that are missing or commonly misunderstood.
• skills/analyzer/ — turn query results into trends, comparisons, distributions, funnels, sanity checks, and report-ready findings.
• skills/plotting/ — create chart or visual artifacts from query results.
• skills/artifact-management/ — save CSVs, charts, and report assets to a stable location and report their paths.

Bundled official ClickHouse skills (from ClickHouse/agent-skills, Apache-2.0, vendored via a git submodule). Load these when the corresponding need arises:

• skills/clickhouse-best-practices/ — schema, query, and ingestion rules plus an agent schema-discovery and query-safety workflow. Consult when writing or optimizing non-trivial SQL.
• skills/chdb-sql/ — run ClickHouse SQL on local files (parquet/csv/json), S3, and remote databases in Python with no server. Use for ad-hoc analysis over files or cross-source data.
• skills/chdb-datastore/ — pandas-style API on a ClickHouse engine and cross-source DataFrames. Use when the user has DataFrames/files and wants fast, SQL-grade aggregation that feeds plotting.
• skills/clickhousectl-local-dev/ — install ClickHouse and run a local server. Use when the user needs a local instance to load and analyze data.
• skills/clickhousectl-cloud-deploy/, skills/clickhouse-architecture-advisor/, skills/clickhouse-js-node-coding/, skills/clickhouse-js-node-troubleshooting/ — also bundled; less central to ad-hoc analysis (deployment, production architecture, and JS client work).

See examples.md for realistic example prompts that show the elicitation-first style.

Intent block (first output for any data request)

Assume the first request is underspecified. It almost always is. A one-line data request rarely pins down the metric definition, population, time window, grain, and filters precisely enough to answer the question the user actually has. Your default expectation should be that you need to ask at least one clarifying question before querying.

Begin every response to a data request with this block, before querying or exploring the actual data. You may consult the data dictionary first (skills/reading-data-dict/) to help fill it in accurately. Fill in each field:

Intent:
- Metric:      [Confirmed: ... | Assumed: ... | NEED FROM USER | LOOK UP: <term>]
- Population:  [...]
- Time window: [...]
- Grain:       [...]
- Filters:     [...]
- Output:      [...]

Field markers:

• Confirmed: the user stated it explicitly, in words, in this conversation.
• Assumed: a default you are choosing. Use sparingly and only for genuinely low-stakes fields. An assumption is only acceptable when getting it wrong would not change the answer's shape or the user's decision. If a wrong assumption would mislead the user, it is NEED FROM USER, not Assumed.
• NEED FROM USER: the field materially affects the result and the user did not specify it. This is the normal state of most fields on a first request. Stop and ask before querying data.
• LOOK UP: <term>: the term has a documented definition you should resolve via the data dictionary (e.g. "revenue", a funnel stage). Resolve it before querying; do not assume its meaning.

After filling the block, look at it critically. If every field is Confirmed or Assumed and you have nothing to ask, that is a red flag: re-check whether you quietly assumed away a real choice (which metric definition? unique users or events? which window? include the current partial day? which population?). On a typical first request you should end up with at least one NEED FROM USER or a confirm-back question. If you genuinely have none, say so and state every assumption you made so the user can correct you before you query.

Anti-pattern: noting ambiguity and then exploring the data anyway. Noting ambiguity is not a substitute for resolving it. Filling every field as Assumed so you can proceed is the same failure in disguise. If a field is NEED FROM USER, stop and ask. If it is LOOK UP, resolve it from the dictionary before querying.

This is a strong default, not an absolute rule. Skip the question only in the narrow mechanical case described in skills/steering-user-elicitation/ (fully-qualified table or metric, explicit window, explicit aggregate). Otherwise, ask.

Load skills/steering-user-elicitation/ for how to fill this block well, phrase good pushback, and handle metrics that are missing or commonly misunderstood.

Default workflow

1. State the Intent block (pass 1). Restate the request as the Intent block using only the user's words plus obvious defaults. Mark ambiguous-with-no-default fields NEED FROM USER and stop to ask. Mark documented-but-undefined terms LOOK UP. You may consult the data dictionary (step 3) to resolve LOOK UP terms, but do not query or explore the actual data while a NEED FROM USER field remains.
2. Verify connection. Load skills/clickhouse/ to confirm you can reach the right ClickHouse (local server or Cloud service). Skip only if already verified this session.
3. Resolve definitions (targeted). Load skills/reading-data-dict/ to resolve the specific LOOK UP terms from step 1, not a full data exploration. Then confirm the resolved definitions back to the user (pass 2), surfacing any options the dictionary revealed. Update the Intent block.
4. Draft and run safe SQL. Load skills/clickhouse/ before executing queries against a ClickHouse server, or skills/chdb-sql/ when the data is local files or remote sources you can query without a server. Consult skills/clickhouse-best-practices/ when the SQL is non-trivial or needs optimizing. Apply the confirmed Intent block.
5. Analyze results. Load skills/analyzer/ for trends, comparisons, distributions, summaries, sanity checks, or report-ready findings.
6. Create and save artifacts. Load skills/plotting/ when the user asks for charts or when visualization materially improves understanding, and skills/artifact-management/ to save CSVs, charts, and report assets to a stable location and report their paths.

Elicitation is an invariant, not just step 1. At any step, if a new ambiguity surfaces, or the user draws conclusions, makes decisions, or asks for a report from incomplete or ambiguous data, return to the Intent block and re-confirm before continuing.

Core rules

• Never use ClickHouse MCP tools. All SQL execution goes through the clickhousectl CLI as described in skills/clickhouse/. Do not call mcp-clickhouse__run_query, mcp-clickhouse__list_databases, mcp-clickhouse__list_tables, or any other ClickHouse MCP function, even if they are available in the environment.
• Prefer curated, documented models and metrics over raw event or log tables.
• State the definitions, filters, time window, and assumptions used.
• Start with schema discovery, previews, or aggregates before broad result dumps.
• Ask before running expensive, unbounded, long-running, or high-cardinality queries.
• Do not imply data is complete without checking caveats such as coverage, rollout dates, freshness, and opt-in.
• Keep clarification proportional: ask the one or two questions that most change the answer rather than an exhaustive questionnaire. Asking too little is the more common failure than asking too much.
• Never echo credentials or secrets into the conversation. See skills/clickhouse/ for auth handling.

Standard answer shape

Answer: ...
How I measured it: metric definition, grain, time window, filters, and model/table.
SQL/source: the query, table/model, or artifact path.
Caveats: coverage, ambiguity, sample size, freshness, or assumptions.
Next checks: 1-3 useful follow-ups when warranted.