write-query

A slash-command skill that turns a natural-language data need into an optimized SQL query for a specific dialect while following best practices. It is invoked as /write-query with a description of the data wanted, and it suits cases ranging from a simple aggregation to a multi-CTE query with joins and aggregations, an optimization against a large partitioned table, or getting dialect-specific syntax for warehouses such as Snowflake, BigQuery, or Postgres.

The workflow first parses the request to identify output columns, filters, aggregations, joins, ordering, and limits, then determines the SQL dialect, asking when it is not already known. Supported dialects named in the doc include PostgreSQL (with Aurora, RDS, Supabase, and Neon), Snowflake, BigQuery, Redshift, Databricks SQL, MySQL (including Aurora MySQL and PlanetScale), SQL Server, DuckDB, and SQLite, and the chosen dialect is remembered for the rest of the session. If a data warehouse MCP server is connected, it discovers schema by searching for relevant tables, inspecting columns and relationships, checking partitioning or clustering keys, and looking for pre-built or materialized views that simplify the query.

Query construction follows explicit best practices: descriptive CTEs for multi-step logic, avoiding SELECT * in production, filtering early, using partition filters, preferring EXISTS over IN for large subqueries, choosing correct JOIN types, avoiding correlated subqueries when a JOIN or window function works, and watching for exploding many-to-many joins. Readability conventions cover comments explaining the why, consistent indentation, and meaningful table aliases. The query is presented with an explanation of each section, performance notes where relevant, and suggestions for common variations, and when a warehouse is connected the skill offers to run the query and analyze the results. Deeper dialect specifics are deferred to the related sql-queries skill.