Write a SQL query for the following request. Request: {request_in_plain_english} Dialect: {sql_dialect} Tables and columns: {schema} Rules: - Use only the tables and columns listed above. If something needed is missing, say so instead of inventing it. - Use CTEs instead of nested subqueries when the query has more than one step. - Add a one-line comment above each CTE explaining what it produces. - After the query, list any assumptions you made (timezone, date boundaries, how NULLs are treated).

Review this SQL query for correctness and performance. ```sql {query} ``` Context: it runs on {sql_dialect}, the largest table is {table} with roughly {row_count} rows, and it currently takes {current_runtime}. Do three things: 1. Explain in plain English what the query returns, step by step. 2. Point out anything that could produce wrong results (join fan-out, NULL handling, off-by-one date ranges). 3. Propose a faster version and explain why it is faster (indexes to add, filters pushed down, avoided full scans). Show the rewritten query in full.

I just received a dataset I have never seen before. Build me an EDA plan. Dataset description: {dataset_description} Columns: {column_list} Business question I ultimately need to answer: {business_question} Output a numbered checklist covering: 1. Data quality checks (missingness, duplicates, impossible values, type mismatches) 2. Univariate summaries worth running, and which columns to prioritize 3. Relationships to test between key variables, with the specific plot or statistic for each 4. Segments or time windows likely to behave differently 5. Three hypotheses this data could support or kill, tied to the business question Keep each item to one line so I can work through it as a checklist.

Help me choose the correct statistical test for this comparison. What I am comparing: {comparison_description} Outcome variable and its type: {outcome_variable} Groups / sample sizes: {groups_and_sizes} Data characteristics I know: {known_characteristics} Answer in this format: - Recommended test, in one line - Assumptions the test requires, and how to check each one against my data - What to use instead if an assumption fails - The exact hypotheses (H0 and H1) in plain English - One common misinterpretation of this test's p-value that I should avoid

Interpret these A/B test results and tell me what decision they support. Metric: {metric} Control: {control_n} users, {control_value} Variant: {variant_n} users, {variant_value} Test duration: {duration} Planned sample size / stopping rule, if any: {stopping_rule} Walk through: 1. The observed lift and its confidence interval 2. Whether the result is statistically significant AND practically meaningful for this metric 3. Red flags to check before trusting it: peeking, sample ratio mismatch, novelty effects, weekday/weekend imbalance 4. A clear recommendation: ship, iterate, or extend the test — and what evidence would change that call Be direct. If the data is inconclusive, say so rather than hedging.

Generate a cleaning plan for this dataset before analysis. Source: {data_source} Sample of the problems I have already noticed: {known_issues} Tool I will clean it in: {tool} For each cleaning step, give me one row with three parts: the issue to check, how to detect it (a concrete rule or snippet in {tool}), and the fix — including when the right fix is to drop rows versus impute versus flag and keep. Cover at minimum: duplicates, missing values, inconsistent categorical labels, outliers, date parsing and timezone issues, and encoding problems. End with the one check I should re-run after cleaning to confirm nothing broke.

Recommend the best chart for what I am trying to show. Data: {data_description} Point I want the audience to take away: {takeaway} Audience: {audience} Give me: 1. The single best chart type, and why it beats the two most obvious alternatives 2. Axis choices, sorting, and any baseline (zero or otherwise) I should use 3. What to remove: gridlines, legends, colors, or series that would dilute the takeaway 4. A one-sentence title for the chart that states the finding, not the topic If the honest answer is 'a table' or 'a single number', say that instead of forcing a chart.

Design a cohort retention analysis for this product. Product: {product_description} What counts as 'active': {active_definition} Data available: {available_tables} Question driving this: {business_question} Lay out: 1. How to define cohorts (signup week vs month, and why for this product) 2. The retention measure to use — classic N-day, unbounded, or bracket — and the tradeoff 3. SQL skeleton for the cohort table (dialect: {sql_dialect}) 4. How to read the triangle: which diagonal or column answers my question 5. Two segmentation cuts most likely to explain differences between cohorts

A key metric moved and I need to find out why. Metric: {metric} What happened: {change_description} starting around {start_date} Recent changes I know about (releases, campaigns, pricing, seasonality): {known_events} Build me a root-cause investigation plan, ordered from cheapest check to most expensive: 1. Data issues first — tracking changes, pipeline failures, definition changes 2. Mix shifts — did the composition of users/traffic change rather than behavior 3. Segment drill-down — which cuts (platform, geo, acquisition channel, user tenure) to slice first and what a smoking gun would look like in each 4. External factors For each step, state what result would let me stop the investigation there.

Turn my analysis notes into an executive summary. Raw notes: {analysis_notes} Audience: {audience}, who will spend at most 60 seconds on this. Format: - Headline: the single most decision-relevant finding, stated as a fact with the number in it - Three supporting bullets, each one line, each with a concrete figure - 'What we recommend': one action, one owner-shaped verb - 'Caveats': the one or two limitations that could change the conclusion — no more Rules: no methodology detail, no hedging language like 'it seems', and never bury the recommendation below the fold. If my notes do not support a clear recommendation, say what additional data would.