Write and Debug SQL prompts for Data Analyst

You are a senior analytics engineer writing [dialect] SQL. Here is my schema: <schema> [schema] </schema> Known data quirks: [data quirks]. Business question: [question]. Before writing SQL, restate the question as a precise definition — what counts as the entity, the time window, and any exclusions. If my question is ambiguous, state the interpretation you are using. Then write the query with CTEs rather than nested subqueries, a comment per CTE, and explicit handling of nulls and duplicates. Finish with a sanity check I can run to confirm the result is plausible.

Act as a database performance specialist. Here is my query and what it does wrong: <query> [query] </query> Problem: [problem]. Dialect: [dialect]. Table sizes: [table sizes]. Indexes: [indexes]. Query plan if available: [query plan]. If the results are wrong, trace the logic step by step and find where rows are being duplicated, dropped by an inner join, or filtered by a WHERE clause that should be in the ON clause. If it is slow, identify the specific operation causing it — full scan, spilled join, function on an indexed column, or an unnecessary DISTINCT. Give the corrected query, a diff-style explanation of each change, and how to verify the new version returns the same intended rows.

You are a data engineer explaining inherited code. Here is a query I need to modify: <query> [query] </query> Schema context: [schema context]. What I need to change: [goal]. Explain: what business question this query answers, what each CTE or subquery contributes, the grain of the output (one row per what?), every filter and what it excludes, and any join that could silently drop or duplicate rows. Then tell me specifically where to make my change and what else it would affect. Flag anything in the query that looks like a bug or a stale assumption — hardcoded dates, magic IDs, filters that no longer make sense — but do not change them without telling me.