Turn business questions into reproducible warehouse analyses

This skill turns 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, and it defaults to read-only work - identifying the data needed, reviewing a proposed query, and communicating results without overstating what the evidence supports.

Before proposing a query it establishes the decision the analysis should inform, the population/metric/dimensions/time window, the authorized warehouse or query interface, relevant schema documentation, and any privacy or minimum-group-size constraints - asking a focused question for anything missing rather than inventing table names, column names, business definitions, credentials, or results. Its seven-step workflow: define the analytical contract (question, population, metric, window, decision), calling out ambiguous terms like "active" or "revenue" to resolve before querying; find governed sources, preferring documented metrics and curated models over raw event streams, recording each source's grain, freshness, and known exclusions, and labeling the plan provisional if a source can't be verified; draft a read-only query only once the real schema is known, selecting only needed columns, filtering the time window explicitly, guarding null/zero-division cases, and avoiding row-level personal data when an aggregate answers the question; review the query against a checklist covering join-grain preservation, one-to-many duplication risk, timezone/partial-period handling, and unnecessary exposure of identifiers or small groups; execute only through a user-authorized, read-only interface, stopping if the interface is unavailable or the scope exceeds authorization; validate the result against a trusted reference, inspect null rates and duplicates, and test whether conclusions hold under reasonable window changes, without inferring causality from a descriptive query; and report with provenance in a compact structure:

Finding: [what the data shows]
Scope: [population and period]
Method: [metric and source summary]
Confidence: [high, medium, or low, with reason]
Caveats: [freshness, exclusions, quality, or privacy limits]
Next step: [optional validation or decision input]

A worked example ("did weekly activated accounts improve after the onboarding change?") shows the pattern end to end: clarify the activation definition and comparison window, locate the governed metric and cohort source, aggregate without selecting account-level identifiers, review for cohort overlap and seasonality, then report the change as an association with confidence and caveats - not as proof of causation.

Use it when a user wants to answer a business question against an authorized data warehouse, needs a proposed SQL query reviewed for grain/join/privacy/interpretation risk, or needs a clear record of an analysis's scope, freshness, and assumptions. It explicitly steps back from warehouse administration, pipeline repair, access escalation, schema mutation, or production data changes - those are out of scope entirely, not just deprioritized.

Input is the business question, the authorized warehouse/query interface, and available schema documentation. Output is a reviewed, read-only query (or query summary) plus a compact provenance report naming the finding, scope, method, confidence level, and caveats.

Analysts and agents answering business questions against a data warehouse who need a disciplined, auditable process - governed sources, a reviewed read-only query, and a provenance-backed report - rather than an ungrounded query against an unverified schema.