Forces the ambiguity out of a business question before any SQL gets written, then produces a query with its assumptions stated on the record.
A stakeholder asked: "{{QUESTION}}" SCHEMA: {{SCHEMA}} DIALECT: {{DIALECT}} Work in three steps and show all three. **Step 1 — Ambiguities.** List every word in the question that could be defined more than one way, with the plausible definitions and which one you'll use. ("Active" alone usually has four.) For each, note whether the choice would materially change the number. **Step 2 — The definition.** Restate the question as a precise, testable one, in the form: "Count of X where Y, over period Z, excluding W." This is what you will actually answer. **Step 3 — The query.** Write it for {{DIALECT}}. Requirements: - Every non-obvious choice gets an inline comment saying why. - CTEs named for what they mean, not `t1`. - Handle nulls, soft deletes, and timezone explicitly — state the timezone. - No `SELECT *`. - If the schema can't answer the question, say exactly what's missing and write the closest honest query instead. Do not invent columns. Then add: - **Sanity checks** — two queries whose results should hold if the main query is right (row-count bounds, a known subtotal, a spot-check on one user). - **How this gets misread** — the one way a reader will misinterpret the number, and the caption to prevent it.
Tools for this prompt
Where the input below comes from. The ones marked needed change the output a lot — fallbacks for each are further down.
This prompt is only as good as what you feed it. Web search covers anything public — these are the inputs it can't reach.
The real schema, which the prompt needs in full — inventing columns is its most common failure.
Don't have it: Ask the user to paste the schema or DDL. Never invent column names.
Running the sanity checks and putting the result somewhere the stakeholder can see it.
Don't have it: Hand back the SQL and sanity checks for the user to run themselves.
Only tools that web search cannot replace are listed. Anything public — reviews, job ads, papers, salary data — an agent can already fetch, so it is not listed here. No paid placements or affiliate links; if that changes, this line will say so.
A prompt is a skill with the serial numbers filed off. Install it once and your agent reaches for it on its own.
Paste this into ChatGPT, Claude Code, Codex, Cursor, or whatever you use:
Install the sql-from-a-vague-question skill globally from https://promptsbuddy.com/prompts/sql-from-a-vague-question/skill.md.claude/skills/sql-from-a-vague-question/SKILL.md
---
name: sql-from-a-vague-question
description: "Forces the ambiguity out of a business question before any SQL gets written, then produces a query with its assumptions stated on the record. Use when the user asks for help with data tasks like sql, analytics, data."
license: CC-BY-4.0
metadata:
source: https://promptsbuddy.com/prompts/sql-from-a-vague-question
author: "Sam Reyes"
version: "2.2"
---
# Vague executive question → SQL that survives review
Forces the ambiguity out of a business question before any SQL gets written, then produces a query with its assumptions stated on the record.
## Inputs to collect first
Ask the user for anything below that they have not already given you. Do not
invent values for these.
- `QUESTION` — The question as it was asked, in the asker's words. (e.g. How many of our customers are actually active?)
- `SCHEMA` — DDL or a column listing for the relevant tables. (e.g. users(id, created_at, deleted_at), events(user_id, name, ts), accounts(id, plan, churned_at))
- `DIALECT` — Warehouse and dialect. (e.g. BigQuery, standard SQL)
## Tools this works with
Do not require any of these. If one is unavailable, use the stated fallback and
say which input is missing rather than inventing it.
- **BigQuery** (needed) — The real schema, which the prompt needs in full — inventing columns is its most common failure.
- Without it: Ask the user to paste the schema or DDL. Never invent column names.
- https://cloud.google.com/bigquery
- **Metabase** — Running the sanity checks and putting the result somewhere the stakeholder can see it.
- Without it: Hand back the SQL and sanity checks for the user to run themselves.
- https://www.metabase.com/
## Instructions
A stakeholder asked: "{{QUESTION}}"
SCHEMA:
{{SCHEMA}}
DIALECT: {{DIALECT}}
Work in three steps and show all three.
**Step 1 — Ambiguities.** List every word in the question that could be defined
more than one way, with the plausible definitions and which one you'll use.
("Active" alone usually has four.) For each, note whether the choice would
materially change the number.
**Step 2 — The definition.** Restate the question as a precise, testable one,
in the form: "Count of X where Y, over period Z, excluding W." This is what you
will actually answer.
**Step 3 — The query.** Write it for {{DIALECT}}. Requirements:
- Every non-obvious choice gets an inline comment saying why.
- CTEs named for what they mean, not `t1`.
- Handle nulls, soft deletes, and timezone explicitly — state the timezone.
- No `SELECT *`.
- If the schema can't answer the question, say exactly what's missing and write
the closest honest query instead. Do not invent columns.
Then add:
- **Sanity checks** — two queries whose results should hold if the main query is
right (row-count bounds, a known subtotal, a spot-check on one user).
- **How this gets misread** — the one way a reader will misinterpret the number,
and the caption to prevent it.
## Notes from people who use this
- Step 1 is the whole prompt. Most 'wrong' dashboards are correct SQL answering a question nobody agreed on.
- Send Step 2 back to the stakeholder before you run anything. Two lines of confirmation saves a day of rework.
- Keep the sanity checks in the PR — reviewers approve queries far faster when they can see them pass.
---
Vague executive question → SQL that survives review · by Sam Reyes · v2.2
From PromptsBuddy — https://promptsbuddy.com/prompts/sql-from-a-vague-question
Licensed CC BY 4.0.
Every prompt is also available at /prompts/sql-from-a-vague-question/skill.md — see all install options.
Analysts don't ship broken SQL very often. They ship correct SQL that answers a slightly different question than the one the executive had in mind, and the gap only surfaces in a board meeting. Pushing the ambiguity list to the front makes that gap visible while it's still cheap.
"Active" is the canonical example. Logged in once ever? In the last 30 days? Performed a value action? Has a paying account attached? Four definitions, four different numbers, all defensible.
Comments that explain why survive code review, get read six months later, and give the next analyst a starting point instead of a puzzle. Comments that restate the SQL are noise. The prompt asks for the former specifically.
Separates what was decided from what was merely discussed, attributes owners, and flags the open questions everyone left the room assuming someone else would answer.
Lena Fischer