Skill Tracer
Skills › Knowledge Work Plugins › write-query

write-query

skill · 122 lines · Apache-2.0 · data/skills/write-query/SKILL.md

The facts

Its 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.

The description the agent reads to decide when to use it.

From its settingsline 3

When it starts

The agent picks this skill when someone asks for a SQL query to be written or optimized — turning a plain-language data need into SQL, building a multi-CTE query with joins and aggregations, tuning a query against a large partitioned table, or needing dialect-specific syntax for Snowflake, BigQuery, Postgres and similar.

Things a person might say (the model's guesses)

  • “Write me a query that counts orders by status for the last 30 days.”
  • “I need a Snowflake query joining users and events to show monthly cohort retention.”
  • “Can you optimize this Postgres query? It's scanning a 500M row table partitioned by date.”

A model's summary of when it is used.

A model's reading

What it takes when started

<description of what data you need>

What to type after its name when you start it.

From its settingsline 4

What it leads to

Other skills this one hands off to, calls, requires or offers instead, as a model read them.

A model's reading

Licence

Apache-2.0, from data/LICENSE

The terms its author shares it under, which let it be shown here.

From the repositorylicence text

The text

Open on GitHub

Most marks come from matching words in the file, so treat them as pointers.

1---
2name: write-query
3description: 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 SQL
8
9> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
11Write a SQL query from a natural language description, optimized for your specific SQL dialect and following best practices.

/write-query - Write Optimized SQL

If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Write a SQL query from a natural language description, optimized for your specific SQL dialect and following best practices.

Raw lines 1 to 12
13## Usage
15```
16/write-query <description of what data you need>
17```

Usage

/write-query <description of what data you need>
Raw lines 13 to 18
19## Workflow

Workflow

Raw lines 19 to 20
21### 1. Understand the Request
23Parse the user's description to identify:
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?

1. Understand the Request

Parse the user's description to identify:

  • Output columns: What fields should the result include?
  • Filters: What conditions limit the data (time ranges, segments, statuses)?
  • Aggregations: Are there GROUP BY operations, counts, sums, averages?
  • Joins: Does this require combining multiple tables?
  • Ordering: How should results be sorted?
  • Limits: Is there a top-N or sample requirement?
Raw lines 21 to 31
32### 2. Determine SQL Dialect
34If the user's SQL dialect is not already known, ask which they use:
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)
47Remember the dialect for future queries in the same session.

2. Determine SQL Dialect

If the user's SQL dialect is not already known, ask which they use:

  • PostgreSQL (including Aurora, RDS, Supabase, Neon)
  • Snowflake
  • BigQuery (Google Cloud)
  • Redshift (Amazon)
  • Databricks SQL
  • MySQL (including Aurora MySQL, PlanetScale)
  • SQL Server (Microsoft)
  • DuckDB
  • SQLite
  • Other (ask for specifics)

Remember the dialect for future queries in the same session.

Raw lines 32 to 48
49### 3. Discover Schema (If Warehouse Connected)
51If a data warehouse MCP server is connected:
531. Search for relevant tables based on the user's description
542. Inspect column names, types, and relationships
553. Check for partitioning or clustering keys that affect performance
564. Look for pre-built views or materialized views that might simplify the query

3. Discover Schema (If Warehouse Connected)

If a data warehouse MCP server is connected:

  1. Search for relevant tables based on the user's description
  2. Inspect column names, types, and relationships
  3. Check for partitioning or clustering keys that affect performance
  4. Look for pre-built views or materialized views that might simplify the query
Raw lines 49 to 57
Uses an outside tool MCP :51
58### 4. Write the Query
60Follow these best practices:
62**Structure:**
63- Use CTEs (WITH clauses) for readability when queries have multiple logical steps
64- One CTE per logical transformation or data source
65- Name CTEs descriptively (e.g., `daily_signups`, `active_users`, `revenue_by_product`)
67**Performance:**
68- Never use `SELECT *` in production queries -- specify only needed columns
69- 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 sets
72- Use appropriate JOIN types (don't use LEFT JOIN when INNER JOIN is correct)
73- Avoid correlated subqueries when a JOIN or window function works
74- Be mindful of exploding joins (many-to-many)
76**Readability:**
77- Add comments explaining the "why" for non-obvious logic
78- Use consistent indentation and formatting
79- Alias tables with meaningful short names (not just `a`, `b`, `c`)
80- Put each major clause on its own line
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 syntax
85- Note any dialect-specific performance features (e.g., Snowflake clustering, BigQuery partitioning)

4. Write the Query

Follow these best practices:

Structure:

  • Use CTEs (WITH clauses) for readability when queries have multiple logical steps
  • One CTE per logical transformation or data source
  • Name CTEs descriptively (e.g., daily_signups, active_users, revenue_by_product)

Performance:

  • Never use SELECT * in production queries -- specify only needed columns
  • Filter early (push WHERE clauses as close to the base tables as possible)
  • Use partition filters when available (especially date partitions)
  • Prefer EXISTS over IN for subqueries with large result sets
  • Use appropriate JOIN types (don't use LEFT JOIN when INNER JOIN is correct)
  • Avoid correlated subqueries when a JOIN or window function works
  • Be mindful of exploding joins (many-to-many)

Readability:

  • Add comments explaining the "why" for non-obvious logic
  • Use consistent indentation and formatting
  • Alias tables with meaningful short names (not just a, b, c)
  • Put each major clause on its own line

Dialect-specific optimizations:

  • Apply dialect-specific syntax and functions (see sql-queries skill for details)
  • Use dialect-appropriate date functions, string functions, and window syntax
  • Note any dialect-specific performance features (e.g., Snowflake clustering, BigQuery partitioning)
Raw lines 58 to 86
Names a skill sql-queries :83
87### 5. Present the Query
89Provide:
911. **The complete query** in a SQL code block with syntax highlighting
922. **Brief explanation** of what each CTE or section does
933. **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)

5. Present the Query

Provide:

  1. The complete query in a SQL code block with syntax highlighting
  2. Brief explanation of what each CTE or section does
  3. Performance notes if relevant (expected cost, partition usage, potential bottlenecks)
  4. Modification suggestions -- how to adjust for common variations (different time range, different granularity, additional filters)
Raw lines 87 to 95
96### 6. Offer to Execute
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.

6. Offer to Execute

If 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.

Raw lines 96 to 99
100## Examples
102**Simple aggregation:**
103```
104/write-query Count of orders by status for the last 30 days
105```
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 signup
110```
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```

Examples

Simple aggregation:

/write-query Count of orders by status for the last 30 days

Complex analysis:

/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

Performance-critical:

/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.
Raw lines 100 to 116
117## Tips
119- Mention your SQL dialect upfront to get the right syntax immediately
120- If you know the table names, include them -- otherwise Claude will help you find them
121- Specify if you need the query to be idempotent (safe to re-run) or one-time
122- For recurring queries, mention if it should be parameterized for date ranges

Tips

  • Mention your SQL dialect upfront to get the right syntax immediately
  • If you know the table names, include them -- otherwise Claude will help you find them
  • Specify if you need the query to be idempotent (safe to re-run) or one-time
  • For recurring queries, mention if it should be parameterized for date ranges
Raw lines 117 to 122

From anthropics/knowledge-work-plugins at 2574e29, 2026-10-27. Skills read by DeepSeek V4.1 Flash on 2026-11-04. Summary and techniques by Claude Opus 5.5 on 2026-11-06.