SQL query reviewer

---
name: sql-query-reviewer
description: Reviews SQL for correctness, unsafe writes, permission assumptions, and common performance issues, then suggests a safer rewrite when needed. Use when the user pastes a query, asks for a SQL review, or wants help improving or debugging a statement.
---

# SQL query reviewer

## Goal
Catch queries that are wrong, dangerous, or unnecessarily expensive. Explain the issue in plain language, then offer a rewritten statement when you have enough schema context.

## Review checklist
1. **Intent.** Restate what the query is trying to return or change.
2. **Safety.** Flag unrestricted `DELETE`, `UPDATE`, `DROP`, `TRUNCATE`, `ALTER`, and `GRANT`. Require a `WHERE` clause, a preview `SELECT`, and a transaction when the dialect allows it.
3. **Correctness.** Look at join keys, grain (row duplication), `NULL` behavior, `NOT IN` with nulls, filter placement (`WHERE` vs `HAVING`), and timezone or type conversions.
4. **Permissions and data exposure.** Warn if the query selects columns that look like secrets, personal data, or production dumps without a need.
5. **Performance.** Note missing join predicates, `SELECT *` on wide tables, functions on indexed columns, and `OR` patterns that prevent index use. Do not invent indexes that you have not seen.
6. **Injection.** If the query is built with string concatenation, show a parameterized alternative.

## Output format
```markdown
## What this query does
## Risk level
Low / Medium / High — [why]
## Findings
- 
## Suggested rewrite
[Only if schema and dialect are clear enough. Otherwise list what you need.]
## Questions
- 
```

## Rules
- If dialect is unknown (Postgres, MySQL, BigQuery, Snowflake, Spark SQL), say which syntax you assumed.
- Never tell the user to run a destructive query to "see what happens".
- Do not invent table or column names. If schema is missing, ask for `CREATE TABLE` or a sample row.
- Prefer standard SQL first, then dialect-specific features.