Warehouse Analysis

Overview

Use this skill to turn a business question into a careful, reproducible warehouse-analysis plan. It is vendor-neutral and assumes no particular schema, semantic layer, connector, or command-line tool.

The skill defaults to read-only work. It helps identify the data needed, review a proposed query, and communicate results without overstating what the evidence supports.

When to Use

• The user wants to answer a business question using an authorized data warehouse.
• A proposed SQL query needs a review for grain, joins, filters, privacy, or interpretation risks.
• An analysis needs a clear record of scope, freshness, assumptions, and source tables.

Do not use this skill for warehouse administration, pipeline repair, access escalation, schema mutation, or production data changes.

Required Inputs

Before proposing a query, establish:

1. The decision or question the analysis should inform.
2. The population, metric, dimensions, and time window.
3. The authorized warehouse or query interface available to the user.
4. The relevant schema documentation or table metadata.
5. Any privacy, retention, regional, or minimum-group-size constraints.

If a required input is missing, ask a focused question. Never invent table names, column names, business definitions, credentials, or query results.

Workflow

1. Define the analytical contract

Restate the request as:

• Question: what is being measured or compared.
• Population: which entities are included and excluded.
• Metric: numerator, denominator, aggregation, and unit.
• Window: dates, timezone, and whether the period is complete.
• Decision: how the result will be used.

Call out ambiguous terms such as “active,” “customer,” “revenue,” or “last month.” Resolve ambiguity before querying.

2. Find governed sources

Prefer documented metrics, curated models, and governed tables over raw event streams. Use only schema information supplied by the user or available through an authorized interface.

For each proposed source, record:

• table or model name;
• expected grain and primary key;
• freshness or maximum available date;
• owner or documentation reference;
• known exclusions and quality warnings.

If the source cannot be verified, label the plan as provisional and stop before presenting numerical conclusions.

3. Draft a read-only query

Create a query only when the real schema is known. The query should:

• select only the columns needed for the stated question;
• filter the requested time window explicitly;
• use qualified column names and deterministic joins;
• guard division by zero and null-sensitive calculations;
• avoid row-level personal data when an aggregate answers the question;
• include a conservative row limit for exploratory output when appropriate.

Do not emit guessed SQL with fictional identifiers. If no authorized execution tool is available, provide the reviewed query for the user to run rather than claiming it was executed.

4. Review before execution

Check the proposed query against this list:

• Does every join preserve the intended grain?
• Can a one-to-many join duplicate the numerator or denominator?
• Are test, deleted, internal, or incomplete records handled deliberately?
• Are timezone boundaries and partial periods explicit?
• Does the query expose identifiers or small groups unnecessarily?
• Would a simpler aggregate answer reduce data access?
• Are metric definitions consistent with the documented source?

Revise any failed check before execution. For sensitive or high-impact decisions, ask for review by the data owner or another qualified analyst.

5. Execute only with authorization

Run a query only through a user-authorized, read-only interface. Do not request credentials in chat, bypass access controls, broaden permissions, or turn a read-only task into a write operation.

Stop if the interface is unavailable, the scope exceeds the user's authorization, or the result would reveal restricted personal or confidential data.

6. Validate the result

Before interpreting output:

• compare row counts and totals with a trusted reference when one exists;
• inspect null rates, duplicates, and unexpected categories;
• test whether conclusions change under reasonable window or filter choices;
• separate observed values from hypotheses about their causes.

Do not infer causality from a descriptive query. Do not hide contradictory or incomplete evidence.

…