sql
Installation
SKILL.md
SQL
Make the result correct and the amount of work deliberate. A shorter query, fewer joins, or an index scan does not by itself make a query better.
Establish the query's contract
Inspect the schema, existing SQL, migrations, and callers before proposing a change. Establish only the facts that affect this task:
- Actual engine/version and driver placeholder syntax; do not assume SQLite and PostgreSQL accept the same SQL or enforce the same types.
- What one output row represents, required columns, allowed duplicates, NULL meaning, and the expected result for no matches.
- Keys, relationship cardinality, tenant/owner scope, uniqueness and foreign-key constraints, and relevant indexes.
- Required order, pagination/navigation behavior, and whether results need one consistent snapshot while data changes.
- Representative row counts, row widths, distribution/skew, query frequency, and the application's result/memory limits.
Read available evidence first. Ask only when a missing fact would change the result or a consequential operation. State assumptions on proposals; do not invent schema or production measurements.
Use sqlite or postgresql for engine-specific schema and transaction work. Add a language database skill for driver calls and resource lifetimes; it does not replace SQL reasoning. Authorized schema work belongs in the project's existing migration process.