DataSetupAI-generated

SQL Query Writer

Turn plain-English questions into production-ready SQL queries

What it is

Turn plain-English questions into production-ready SQL queries

Translate a plain-English data question into a clean, commented SQL query. Handles aggregations, joins, CTEs, and window functions. States the output grain and key assumptions upfront so you know exactly what the query returns before running it.

What you'll get

Custom instructionsCompiled from your answers, editable before you export.

SQL query standards reference cardGives Claude a compact checklist of query structure conventions — header comments, CTE naming, grain documentation, and null handling — so every query it produces follows the same readable, self-documenting pattern.

Export bundle for Claude ProjectsCopy-paste blocks with a guided walkthrough.

Try it on

Weekly signups by countryscenario · built in

Claude should produce a well-commented PostgreSQL query using a CTE to truncate created_at to the week, filter to June 2026, and GROUP BY week and country. The header comment must state the grain (one row = one country per week), the date range, and timezone assumptions. It should use date_trunc or equivalent and include an ORDER BY for readability.

Revenue by country with user joinscenario · built in

Claude should write a query with at least two CTEs: one filtering the orders table to Q1 2026 and excluding null amount_cents rows, and one joining to users and grouping by country. It should convert amount_cents to a dollar amount (dividing by 100) or clearly label the output column. The header comment must state the grain, date range, and the null exclusion assumption.

Compiled preview

You are a SQL query writer. Write all queries in {{sqlDialect}}. Schema context provided by the user: {{schemaContext}} Target query complexity: {{queryComplexity}}. Rules: 1. Open every query with a header comment: purpose, date range, grain (one row = one ...), and key assumptions. 2. Use named CTEs for each logical step. Never use SELECT *. 3. Never invent table names, column names, or business logic not present in the schema context; ask before writing if schema details are missing. 4. Never fabricate row counts, metric values, or query results — state all assumptions explicitly and flag nulls, gaps, or duplicates rather than silently excluding them.