Use sql-review

Review a SQL query for correctness first and performance second

Review a SQL query for correctness first and performance second — join fan-out inflating sums, NULL traps in filters and NOT IN, timezone and date-boundary errors, integer division, DISTINCT hiding a bad join, window-frame defaults, implicit casts, non-sargable predicates and missing partition filters — with each finding tied to a line, the wrong number it produces, and corrected SQL for the named dialect.

Reach for it when the user pastes a query and asks "is this right", "review my SQL", "why is this number too high", "check this before it goes in the dashboard", or "make this query faster".

Install it

npx skilldrop-cli install sql-review                 # Claude Code, your user folder
npx skilldrop-cli install sql-review --project       # Claude Code, this repo
npx skilldrop-cli install sql-review --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Data and analytics pack: --pack data-analytics installs it with its neighbours.

It ships scripts, so it needs Python 3 (standard library only, nothing to install). What they may touch is declared in its manifest.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Is this SQL right? Revenue by region looks about double what finance has"
• "Review my BigQuery query before I put it in the dashboard"
• "Why does my refund rate come back as 0 in Postgres? Here's the query"
• "This Snowflake query is correct but slow and expensive, can you tune it?"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Design the tables and indexes for our new orders service"
• "Write a data contract for the orders table the finance team consumes"
• "Define exactly how we calculate net revenue retention so everyone uses the same formula"

If another skill answers instead, ask for this one by name: "use sql-review".

Check what you get

A good result:

• Correctness findings come before performance findings, and a query with an open 🟥 is never given performance advice as its headline.
• Every finding names a line, the wrong result it produces, and corrected SQL. A finding without a fix is a complaint.
• The wrong result is stated in business terms, such as "refund rate always shows 0", not as "integer division issue".
• Fixes are in the user's dialect. No SAFE_DIVIDE in a Postgres review, no ::numeric in BigQuery.
• Join fan-out is checked for every join, even when the lint is clean.
• A full corrected query is provided, plus verification queries that would show whether the fix worked.
• Lint hits are triaged, not pasted. Each one is confirmed or dismissed with a reason.
• Nothing about the schema is invented. Key uniqueness, column types and timezones not given are listed as assumptions with a query to check each.

See a worked example

• revenue by region

Use something else when

• Deciding what a metric should mean (formula, filters, owner) — that's the metric owner's call; this skill checks that SQL computes it correctly
• Designing tables, keys and indexes from access patterns — this reviews queries against a schema, not the schema
• Agreeing a dataset's schema, quality SLAs and change policy with its consumers — that's data-contract
• General application code review, including SQL built in application code for security — that's pre-merge-review

Where a loop runs it

• Stage review of the measure loop, where gate G9 decides

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: data-contract, pre-merge-review

Edit this page on GitHub · View source