Agents / Skills

SQL Review

Skill

Reviews a query for the two things that matter: does it answer the question it claims to answer, and will it behave at real data sizes — catching the silent joins that double rows and the predicates that defeat every index.

Best for

  • The query feeding a decision, checked before the decision
  • Analysts' SQL that is correct on the sample and wrong at scale
  • The report that 'looks off' and needs its logic audited

What you give it

  • The query, the question it is supposed to answer, and access to the schema (data access helps but is optional)

What you get back

  • The correctness audit: where the query's logic diverges from its stated question — fan-outs, filter placement, null traps, time-zone edges
  • The performance read: how this executes at real sizes, and the rewrites that keep the answer while fixing the cost
  • The corrected query with the differences explained — so the lesson travels beyond this one query

How it works

  1. Audits against the stated question, clause by clause: grain in, grain out, what each join does to row counts, what each filter excludes — including what it excludes by accident.
  2. Hunts the classic silent killers: fan-out joins counted as facts, WHERE-filters that defeat LEFT joins, NULL comparisons that drop rows, DISTINCT papering over a join bug, time zones and date boundaries.
  3. Reads the execution reality: the plan where available, the anti-patterns (functions on indexed columns, leading wildcards, correlated subqueries at scale) where not.
  4. Returns the corrected query with each change explained — review that does not teach gets repeated.

Example

You: Review the churn query behind next week's board number.

Result: Two correctness findings that changed the number: the join to subscriptions fans out for customers with multiple plans (the count was counting plan-rows, not customers — fixed with pre-aggregation; the churn rate moved from 7.2% to 5.8%), and the left join's filter in the WHERE clause silently converted it to inner (the never-subscribed cohort vanished — moved to the join condition). One performance finding: the date function wrapped around the timestamp column defeated the index (rewritten as a range; 40s to 0.8s). The board got 5.8%, with the audit note attached.

Limits — please read

  • Verification against data needs data access; without it the audit is structural (and says so).
  • The stated question must actually be stated; 'is this query right' without the question gets the question asked back.
  • Dialect specifics are checked for the engine you name.