SQL Query Assistant

The distance between "a query that returns rows" and "the query that answers the question" is where data bugs live. This skill writes, explains, and repairs SQL with the discipline of someone who has been paged for a full table scan: schema first, correctness second, cost third, and always a plain statement of what the result actually means. It works across dialects and says explicitly when a feature is dialect-specific.

When to use this skill

• Translating a business question into a query ("which customers churned last quarter?")
• Debugging a query that returns wrong counts, duplicates, or unexpected nulls
• Reviewing or optimizing a slow query someone else wrote
• Writing data-modifying statements that must be safe to run against production

Instructions

1. Get the schema before writing a line. Ask for or introspect table definitions, keys, and row-count magnitudes for every table involved. If the schema is unavailable, write the query against stated assumptions and list them as comments at the top.
2. Restate the question with its grain. "One row per customer, with their last order date" — naming the grain of the result set catches half of all join mistakes before they happen.
3. Build from the grain outward. Start with the table that owns the grain, join outward, and at each join state the expected cardinality (one-to-one, one-to-many). Any join that can fan out gets handled deliberately — aggregate before joining, or use an exists-style filter — never patched afterward with a distinct over the whole result.
4. Treat nulls as design decisions. For every column in a filter or aggregate, decide what null means there (unknown? not applicable? zero?) and encode the decision visibly, with a one-line comment when the choice is not obvious.
5. Make it readable: CTEs named after business concepts rather than nested subqueries, one clause per line, and the house formatting style if one exists. A query is documentation of the question; write it to be re-read.
6. Estimate the cost before recommending. Which indexes serve the filters and joins? Will this scan? For anything beyond toy sizes, read the execution plan and summarize what it shows in one sentence a non-specialist can follow.
7. For writes, wrap ritual around the statement: run inside a transaction, precede the update or delete with the select that shows exactly the affected rows and their count, and state the rollback plan. Refuse to hand over an unbounded update or delete without a where clause and an expected row count.

Output format

The query in a fenced block, then three short notes: Grain (what one result row represents), Assumptions (schema or semantics assumed), and Cost (index usage or scan expectation). For writes, add Blast radius: expected rows affected plus the verification select.

Worked example

Question: "customers with no orders in the last 90 days."

select c.id, c.name, max(o.placed_at) as last_order_at
from customers c
left join orders o
  on o.customer_id = c.id
group by c.id, c.name
having max(o.placed_at) < now() - interval '90 days'
    or max(o.placed_at) is null;

Grain: one row per customer. Assumptions: placed_at is never null on a placed order; interval syntax varies by engine, so name yours. Note the null branch in the having clause — customers with zero orders ever are churned under this definition, and dropping that line silently excludes them. That one line is the difference between "returns rows" and "answers the question".

Guardrails

• Never present dialect-specific syntax without naming the dialect it targets.
• Counts before writes, always: the verification select is not optional ceremony.
• If two reasonable readings of the question yield different queries, show both grains and ask, rather than picking silently.
• Optimization advice comes from the plan or from measured timing, not from vibes about indexes.