Write a SQL query

SQL prompts fail when the schema is implied rather than stated. Give the model the tables and the ambiguity disappears.

When to use it

Any query against a schema with soft deletes, status flags, or other traps that are obvious to you and invisible to the model.

What it prevents

A query that is correct against the schema you described and wrong against the schema you have. Stating the soft-delete and refund rules explicitly is the difference.

The prompt

Write a SQL query that returns the ten customers with the highest total spend in the last 90 days.

### Context
Postgres. The orders table has soft deletes, and refunded orders must not count toward spend.

### Requirements
- Exclude rows where deleted_at is not null, and where status is 'refunded'.
- Return customer id, name, and total spend, ordered by spend descending.
- Output format: A single SQL code block, then one sentence on which index would make it fast.
- Avoid: window functions where a simple aggregate will do.

### Schema
"""
customers(id, name)
orders(id, customer_id, amount, status, deleted_at, created_at)
"""

Why each part is there

Every section of that prompt exists because a specific failure happens without it. These are the checks it passes, and what each one is protecting you from:

• States a concrete task — why this matters
• Avoids vague language — why this matters
• Specifies an output format — why this matters
• Gives context or audience — why this matters
• Avoids dangling references — why this matters
• Avoids over-aggressive phrasing — why this matters
• Defines what a good answer looks like — why this matters

How to adapt this one

Replace the question and paste your real schema — the tables, the columns, and every trap the model cannot see: soft deletes, status enums, multi-currency amounts, timezone columns. The schema block is the prompt. A query is only correct against the schema it was told about, so an omitted deleted_at column is a silently wrong result waiting to happen.

The mistake this prompt avoids

Describing the data in prose instead of pasting the schema. “A table of orders with customers” leaves the model to invent column names and miss the soft-delete flag entirely. Paste the actual DDL or a column list. The five seconds it takes is the difference between a query that runs and one that runs and lies.

A variation

Need the query fast, not just correct? Add the row counts and the existing indexes to the context and ask for the query plus the one index that would make it sargable. A model that knows the orders table has 40 million rows writes a different query from one that assumes a thousand — and will tell you which index to add if you ask.

Check your version

Once you have adapted it, run it through the checker. The same nine checks that graded this page will grade yours, free and in your browser — paste it in, or build one from scratch by answering a few questions.