{
  "schema": "https://ai-atoms.com/schemas/skill-v1.json",
  "type": "skill",
  "id": "skill/write-query",
  "version": "1.0.0",
  "name": "write-query",
  "description": "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.",
  "system_prompt_fragment": "# /write-query - Write Optimized SQL\n\n> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).\n\nWrite a SQL query from a natural language description, optimized for your specific SQL dialect and following best practices.\n\n## Usage\n\n```\n/write-query <description of what data you need>\n```\n\n## Workflow\n\n### 1. Understand the Request\n\nParse the user's description to identify:\n\n- **Output columns**: What fields should the result include?\n- **Filters**: What conditions limit the data (time ranges, segments, statuses)?\n- **Aggregations**: Are there GROUP BY operations, counts, sums, averages?\n- **Joins**: Does this require combining multiple tables?\n- **Ordering**: How should results be sorted?\n- **Limits**: Is there a top-N or sample requirement?\n\n### 2. Determine SQL Dialect\n\nIf the user's SQL dialect is not already known, ask which they use:\n\n- **PostgreSQL** (including Aurora, RDS, Supabase, Neon)\n- **Snowflake**\n- **BigQuery** (Google Cloud)\n- **Redshift** (Amazon)\n- **Databricks SQL**\n- **MySQL** (including Aurora MySQL, PlanetScale)\n- **SQL Server** (Microsoft)\n- **DuckDB**\n- **SQLite**\n- **Other** (ask for specifics)\n\nRemember the dialect for future queries in the same session.\n\n### 3. Discover Schema (If Warehouse Connected)\n\nIf a data warehouse MCP server is connected:\n\n1. Search for relevant tables based on the user's description\n2. Inspect column names, types, and relationships\n3. Check for partitioning or clustering keys that affect performance\n4. Look for pre-built views or materialized views that might simplify the query\n\n### 4. Write the Query\n\nFollow these best practices:\n\n**Structure:**\n- Use CTEs (WITH clauses) for readability when queries have multiple logical steps\n- One CTE per logical transformation or data source\n- Name CTEs descriptively (e.g., `daily_signups`, `active_users`, `revenue_by_product`)\n\n**Performance:**\n- Never use `SELECT *` in production queries -- specify only needed columns\n- Filter early (push WHERE clauses as close to the base tables as possible)\n- Use partition filters when available (especially date partitions)\n- Prefer `EXISTS` over `IN` for subqueries with large result sets\n- Use appropriate JOIN types (don't use LEFT JOIN when INNER JOIN is correct)\n- Avoid correlated subqueries when a JOIN or window function works\n- Be mindful of exploding joins (many-to-many)\n\n**Readability:**\n- Add comments explaining the \"why\" for non-obvious logic\n- Use consistent indentation and formatting\n- Alias tables with meaningful short names (not just `a`, `b`, `c`)\n- Put each major clause on its own line\n\n**Dialect-specific optimizations:**\n- Apply dialect-specific syntax and functions (see `sql-queries` skill for details)\n- Use dialect-appropriate date functions, string functions, and window syntax\n- Note any dialect-specific performance features (e.g., Snowflake clustering, BigQuery partitioning)\n\n### 5. Present the Query\n\nProvide:\n\n1. **The complete query** in a SQL code block with syntax highlighting\n2. **Brief explanation** of what each CTE or section does\n3. **Performance notes** if relevant (expected cost, partition usage, potential bottlenecks)\n4. **Modification suggestions** -- how to adjust for common variations (different time range, different granularity, additional filters)\n\n### 6. Offer to Execute\n\nIf 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.\n\n## Examples\n\n**Simple aggregation:**\n```\n/write-query Count of orders by status for the last 30 days\n```\n\n**Complex analysis:**\n```\n/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 signup\n```\n\n**Performance-critical:**\n```\n/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.\n```\n\n## Tips\n\n- Mention your SQL dialect upfront to get the right syntax immediately\n- If you know the table names, include them -- otherwise Claude will help you find them\n- Specify if you need the query to be idempotent (safe to re-run) or one-time\n- For recurring queries, mention if it should be parameterized for date ranges",
  "applicable_domains": [
    "data",
    "analytics"
  ],
  "invocation": [
    "/write-query",
    "/write-query <description of what data you need>"
  ],
  "tags": [
    "data",
    "anthropics",
    "knowledge-work"
  ],
  "authored_by": "anthropics",
  "source_url": "https://github.com/anthropics/knowledge-work-plugins/blob/main/data/skills/write-query/SKILL.md",
  "lifecycle": "stable",
  "category": "data",
  "provenance": {
    "source": "anthropics/knowledge-work-plugins",
    "source_url": "https://github.com/anthropics/knowledge-work-plugins/blob/main/data/skills/write-query/SKILL.md",
    "author": "Anthropic",
    "license": "Apache-2.0",
    "notes": "Imported by scripts/import-anthropic-skills.py."
  }
}