SQL is the lifeline of data work-one wrong JOIN can drag a production database to its knees; gut-feel data analysis skews conclusions. Tossing a raw "write me a SQL" or "analyze this data" at an LLM gets you either a query in the wrong dialect that won't run, or fabricated conclusions. This pack is split into three levels: beginner writes one correct query, intermediate explains and optimizes an existing query, expert chains through profile -> clean -> analyze -> visualize in one go. The three load-bearing constraints-paste the schema, name the dialect, go step by step-are what pull the AI from guessing back to grounded work. Aimed at data analysts, backend engineers, product managers-anyone who deals with tables and doesn't want to be misled by the AI.
Beginner: Write One Correct SQL
When you know what to query but don't want to hand-write the JOINs and aggregations. The point isn't getting the AI to "produce SQL"-it's getting SQL that actually runs on your database and doesn't return a full-table scan.
You are a senior data analyst. Write a SQL query in {{MySQL / PostgreSQL / SQLite / BigQuery}} dialect:
- Query goal: {{one sentence, e.g. "total order amount per paying user in the last 30 days, top 20 by amount desc"}}
- Schema: {{paste CREATE TABLE, or "table name + columns + types"}}
Constraints:
1. Output only the SQL code block, no explanation
2. Quote identifiers per dialect (MySQL uses backticks, PostgreSQL uses double quotes)
3. Explicit JOIN ... ON, no comma-style implicit joins
4. Always include LIMIT
5. Write date logic per dialect (MySQL DATE_SUB, PG INTERVAL)Why these constraints: dialect mismatch is the #1 cause of SQL breakage-DATE_SUB errors out on PostgreSQL; explicit JOIN ... ON avoids missing ON conditions that produce cartesian products; forced LIMIT stops the AI from writing SELECT * and dragging the database. Pasting CREATE TABLE beats "describing fields"-the AI sees types and primary keys, so its aggregations and JOINs match reality. When you don't have a CREATE TABLE, at least give "table name + column name + type + primary key"-don't just say "users table and orders table," or the AI will invent column names and produce a list of columns that don't exist.
Intermediate: Explain and Optimize a Query (with Variables)
When you inherit someone else's SQL, or an AI-generated one, and want to confirm what it actually does and where the traps are. Better than "take a look at this SQL" because it forces the AI to check item by item instead of vaguely saying "could be optimized."
You are a senior DBA. For the SQL below, output in order:
1. One-line summary: what it queries and at what granularity the result is
2. Step-by-step breakdown: the role of FROM / JOIN / WHERE / GROUP BY / HAVING / ORDER BY
3. Potential issues (1-3), each tagged with a type:
- Index not hit (function wrapped on a column, implicit type conversion)
- Cartesian product or missing ON
- N+1 query
- Full-table scan / SELECT *
4. Optimized SQL, marking each change and why
Constraint: don't rewrite unrelated parts; minimal changes; if unsure, mark "needs EXPLAIN plan"
SQL: {{paste}}
Schema and indexes: {{paste, optional}}Variables make this prompt reusable across SQL queries-you only swap the SQL and schema. Tagging "issue type" pulls the AI's attention away from nitpicking formatting toward real performance and correctness problems-quotes and indentation it loves to flag but don't matter get filtered out by the constraint. Common catches: WHERE DATE(created_at) = '2026-07-31' wraps a function around a column and kills the index; the AI tags it "index not hit" and rewrites it as a range scan. WHERE status = 1 where status is a varchar also misses the index via implicit conversion.
Expert: Chained Data Analysis
When you get an unfamiliar table or CSV and don't know where to start. One prompt chains five steps, each waiting for your confirmation before continuing-better than a one-shot "analyze this" because every step builds on the previous step's real output, so the AI can't fabricate data.
You are a senior data analyst. I have a dataset. Execute five steps in order; after each step, wait for me to reply "continue" before proceeding:
1. Data profile: from the fields and sample rows, infer each field's type, missing rate, and suspicious values (e.g. age=999, negative amount)
2. Cleaning plan: list dirty-data categories (nulls / duplicate rows / outliers / inconsistent units / encoding mess), with handling advice and trade-offs for each
3. Analysis angles: for the question I want to answer "{{analysis goal}}", give 3 angles and what each can answer
4. Code: for each angle, provide SQL or Pandas code, noting prerequisites (e.g. "requires cleaning the amount field first")
5. Visualization advice: for each result, recommend a chart type (bar / line / scatter / box / heatmap) and explain why that chart best conveys the conclusion
Data fields: {{paste}}
Sample rows (5-10): {{paste}}
Analysis goal: {{one sentence, e.g. "find shared traits of churned users"}}The chain's value is "wait for confirmation after each step": field problems exposed in step 1 directly reshape step 2's cleaning plan, which reshapes step 3's analysis angles-a one-shot prompt can't form this feedback loop. Visualization gets its own step because the AI defaults to stacking bar charts; forcing it to say "why this chart" pulls the choice back to data characteristics: time series -> line, distribution -> box, correlation -> scatter. How well you write the analysis goal decides the whole chain's direction: writing "analyze this data" only yields vague angles; writing "find shared traits of users who churned within 30 days of paying" gives a sharp entry point, and step 3's angles will actually orbit that question.
With vs Without, What's the Difference
Without a prompt, saying "write a SQL" leaves the AI unaware of dialect and schema, often handing you a generic query that won't run; saying "analyze this data" gets fabricated conclusions or mindless bar charts. With this pack, three hard constraints pull the result from guesswork to grounded work: paste CREATE TABLE so the AI sees real types and keys, name the dialect to avoid incompatible functions, and chain in steps so each step builds on the previous output rather than speculation. Beginner is enough for daily data pulls, intermediate suits inheriting someone else's SQL, expert fits facing an unfamiliar dataset for a full analysis. Pick the level by need-don't jump straight to the chain: a simple data pull is faster with the beginner prompt, and the expert's five steps are overkill for a single SELECT.
Sources
- Anthropic Prompt Engineering overview (structured, step-by-step, context-anchored principles): https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
- OpenAI Prompt Engineering guide (clear instructions, split into steps, provide examples): https://platform.openai.com/docs/guides/prompt-engineering
- DAIR.AI Prompting Guide (Chain-of-Thought, Few-Shot and other techniques): https://www.promptingguide.ai/
- Google Gemini API prompting strategies (specify format, step-by-step guidance): https://ai.google.dev/gemini-api/docs/prompting-strategies