Write Query

1---2name: write-query3description: Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.4argument-hint: "<description of what data you need>"5---6 7# /write-query - Write Optimized SQL8 9> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).10 11Write a SQL query from a natural language description, optimized for your specific SQL dialect and following best practices.12 13## Usage14 15```16/write-query <description of what data you need>17```18 19## Workflow20 21### 1. Understand the Request22 23Parse the user's description to identify:24 25- **Output columns**: What fields should the result include?26- **Filters**: What conditions limit the data (time ranges, segments, statuses)?27- **Aggregations**: Are there GROUP BY operations, counts, sums, averages?28- **Joins**: Does this require combining multiple tables?29- **Ordering**: How should results be sorted?30- **Limits**: Is there a top-N or sample requirement?31 32### 2. Determine SQL Dialect33 34If the user's SQL dialect is not already known, ask which they use:35 36- **PostgreSQL** (including Aurora, RDS, Supabase, Neon)37- **Snowflake**38- **BigQuery** (Google Cloud)39- **Redshift** (Amazon)40- **Databricks SQL**41- **MySQL** (including Aurora MySQL, PlanetScale)42- **SQL Server** (Microsoft)43- **DuckDB**44- **SQLite**45- **Other** (ask for specifics)46 47Remember the dialect for future queries in the same session.48 49### 3. Discover Schema (If Warehouse Connected)50 51If a data warehouse MCP server is connected:52 531. Search for relevant tables based on the user's description542. Inspect column names, types, and relationships553. Check for partitioning or clustering keys that affect performance564. Look for pre-built views or materialized views that might simplify the query57 58### 4. Write the Query59 60Follow these best practices:61 62**Structure:**63- Use CTEs (WITH clauses) for readability when queries have multiple logical steps64- One CTE per logical transformation or data source65- Name CTEs descriptively (e.g., `daily_signups`, `active_users`, `revenue_by_product`)66 67**Performance:**68- Never use `SELECT *` in production queries -- specify only needed columns69- Filter early (push WHERE clauses as close to the base tables as possible)70- Use partition filters when available (especially date partitions)71- Prefer `EXISTS` over `IN` for subqueries with large result sets72- Use appropriate JOIN types (don't use LEFT JOIN when INNER JOIN is correct)73- Avoid correlated subqueries when a JOIN or window function works74- Be mindful of exploding joins (many-to-many)75 76**Readability:**77- Add comments explaining the "why" for non-obvious logic78- Use consistent indentation and formatting79- Alias tables with meaningful short names (not just `a`, `b`, `c`)80- Put each major clause on its own line81 82**Dialect-specific optimizations:**83- Apply dialect-specific syntax and functions (see `sql-queries` skill for details)84- Use dialect-appropriate date functions, string functions, and window syntax85- Note any dialect-specific performance features (e.g., Snowflake clustering, BigQuery partitioning)86 87### 5. Present the Query88 89Provide:90 911. **The complete query** in a SQL code block with syntax highlighting922. **Brief explanation** of what each CTE or section does933. **Performance notes** if relevant (expected cost, partition usage, potential bottlenecks)944. **Modification suggestions** -- how to adjust for common variations (different time range, different granularity, additional filters)95 96### 6. Offer to Execute97 98If a data warehouse is connected, offer to run the query and analyze the results. If the user wants to run it themselves, the query is ready to copy-paste.99 100## Examples101 102**Simple aggregation:**103```104/write-query Count of orders by status for the last 30 days105```106 107**Complex analysis:**108```109/write-query Cohort retention analysis -- group users by their signup month, then show what percentage are still active (had at least one event) at 1, 3, 6, and 12 months after signup110```111 112**Performance-critical:**113```114/write-query We have a 500M row events table partitioned by date. Find the top 100 users by event count in the last 7 days with their most recent event type.115```116 117## Tips118 119- Mention your SQL dialect upfront to get the right syntax immediately120- If you know the table names, include them -- otherwise Claude will help you find them121- Specify if you need the query to be idempotent (safe to re-run) or one-time122- For recurring queries, mention if it should be parameterized for date ranges