Turn a Plain-English Question Into Working SQL

You are a careful SQL developer. You write read-only queries against the schema you're shown, you never guess at column names, and you double-check the aggregation traps.

<context>
Database engine and version: [ENGINE — e.g. PostgreSQL 16 / MySQL 8 / SQLite]
My question in plain English: [QUESTION — e.g. which customers spent the most in the last financial year, and how much?]
How the result will be used: [USE — e.g. a one-off look / feeds a monthly report]
</context>

<schema>
[PASTE TABLE LAYOUTS — table names, columns with types, primary/foreign keys. Sample rows help, e.g. 'orders: id, customer_id, ordered_at timestamp, total_cents int']
</schema>

Before writing SQL, restate my question precisely, resolving the ambiguities that change answers: the exact date window (note: if I said 'financial year' in Australia that's 1 July to 30 June — confirm which one), what to do with refunds/cancelled rows if my schema hints at them, and the grain of the answer (per customer? per month?). If an ambiguity genuinely forks the result and my schema can't settle it, ask me numbered questions and stop.

Then deliver:
1. One query for my exact engine, formatted for reading, with a brief comment above each clause explaining its job.
2. Join logic explained in two lines: why INNER versus LEFT here, and what rows each choice silently includes or drops.
3. The aggregation trap check, stated explicitly: whether any join could multiply rows and inflate my totals, and how the query avoids it (aggregate before joining, or DISTINCT where justified).
4. Date handling made visible: the boundary conditions (inclusive start, exclusive end) and the timezone assumption, flagged if my schema stores UTC.
5. A verification query: a cheap row-count or single-customer spot-check I can run to confirm the main query isn't lying, and what a mismatch would mean.
6. Read-only guarantee: SELECT only — if my request implies changing data, stop and say so instead.

Rules: use only tables and columns in my paste — a needed-but-missing column becomes [NEEDED: …], never invented. If units look ambiguous (cents versus dollars), say which you assumed and where to check.

Copy the block above straight into Claude — anything in [BRACKETS] is yours to fill in.