write-query

Name: write-query
Author: anthropics

23kstars2.7kforks

How to install write-query?

anthropics/knowledge-work-plugins/write-query

$npx -y skills add anthropics/knowledge-work-plugins --skill write-query

Installs into the current project.

Summary

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, Bi

Files · 1

View on GitHub

SKILL.md

1	# /write-query - Write Optimized SQL
2
3	> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
4
5	Write a SQL query from a natural language description, optimized for your specific SQL dialect and following best practices.
6
7	## Usage
8
9	```
10	/write-query <description of what data you need>
11	```
12
13	## Workflow
14
15	### 1. Understand the Request
16
17	Parse the user's description to identify:
18
19	- Output columns: What fields should the result include?
20	- Filters: What conditions limit the data (time ranges, segments, statuses)?
21	- Aggregations: Are there GROUP BY operations, counts, sums, averages?
22	- Joins: Does this require combining multiple tables?
23	- Ordering: How should results be sorted?
24	- Limits: Is there a top-N or sample requirement?
25
26	### 2. Determine SQL Dialect
27
28	If the user's SQL dialect is not already known, ask which they use:
29
30	- PostgreSQL (including Aurora, RDS, Supabase, Neon)
31	- Snowflake
32	- BigQuery (Google Cloud)
33	- Redshift (Amazon)
34	- Databricks SQL
35	- MySQL (including Aurora MySQL, PlanetScale)
36	- SQL Server (Microsoft)
37	- DuckDB
38	- SQLite
39	- Other (ask for specifics)
40
41	Remember the dialect for future queries in the same session.
42
43	### 3. Discover Schema (If Warehouse Connected)
44
45	If a data warehouse MCP server is connected:
46
47	1. Search for relevant tables based on the user's description
48	2. Inspect column names, types, and relationships
49	3. Check for partitioning or clustering keys that affect performance
50	4. Look for pre-built views or materialized views that might simplify the query
51
52	### 4. Write the Query
53
54	Follow these best practices:
55
56	Structure:
57	- Use CTEs (WITH clauses) for readability when queries have multiple logical steps
58	- One CTE per logical transformation or data source
59	- Name CTEs descriptively (e.g., `daily_signups`, `active_users`, `revenue_by_product`)
60
61	Performance:
62	- Never use `SELECT *` in production queries -- specify only needed columns
63	- Filter early (push WHERE clauses as close to the base tables as possible)
64	- Use partition filters when available (especially date partitions)
65	- Prefer `EXISTS` over `IN` for subqueries with large result sets
66	- Use appropriate JOIN types (don't use LEFT JOIN when INNER JOIN is correct)
67	- Avoid correlated subqueries when a JOIN or window function works
68	- Be mindful of exploding joins (many-to-many)
69
70	Readability:
71	- Add comments explaining the "why" for non-obvious logic
72	- Use consistent indentation and formatting
73	- Alias tables with meaningful short names (not just `a`, `b`, `c`)
74	- Put each major clause on its own line
75
76	Dialect-specific optimizations:
77	- Apply dialect-specific syntax and functions (see `sql-queries` skill for details)
78	- Use dialect-appropriate date functions, string functions, and window syntax
79	- Note any dialect-specific performance features (e.g., Snowflake clustering, BigQuery partitioning)
80
81	### 5. Present the Query
82
83	Provide:
84
85	1. The complete query in a SQL code block with syntax highlighting
86	2. Brief explanation of what each CTE or section does
87	3. Performance notes if relevant (expected cost, partition usage, potential bottlenecks)
88	4. Modification suggestions -- how to adjust for common variations (different time range, different granularity, additional filters)
89
90	### 6. Offer to Execute
91
92	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.
93
94	## Examples
95
96	Simple aggregation:
97	```
98	/write-query Count of orders by status for the last 30 days
99	```
100
101	Complex analysis:
102	```
103	/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
104	```
105
106	Performance-critical:
107	```
108	/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.
109	```
110
111	## Tips
112
113	- Mention your SQL dialect upfront to get the right syntax immediately
114	- If you know the table names, include them -- otherwise Claude will help you find them
115	- Specify if you need the query to be idempotent (safe to re-run) or one-time
116	- For recurring queries, mention if it should be parameterized for date ranges

People who liked this also viewed

6 picks

Type

write-query

23kstars2.7kforks

View on GitHub

How to install write-query?

anthropics/knowledge-work-plugins/write-query

$npx -y skills add anthropics/knowledge-work-plugins --skill write-query

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# /write-query - Write Optimized SQL
2
3	> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
4
5	Write a SQL query from a natural language description, optimized for your specific SQL dialect and following best practices.
6
7	## Usage
8
9	```
10	/write-query <description of what data you need>
11	```
12
13	## Workflow
14
15	### 1. Understand the Request
16
17	Parse the user's description to identify:
18
19	- Output columns: What fields should the result include?
20	- Filters: What conditions limit the data (time ranges, segments, statuses)?
21	- Aggregations: Are there GROUP BY operations, counts, sums, averages?
22	- Joins: Does this require combining multiple tables?
23	- Ordering: How should results be sorted?
24	- Limits: Is there a top-N or sample requirement?
25
26	### 2. Determine SQL Dialect
27
28	If the user's SQL dialect is not already known, ask which they use:
29
30	- PostgreSQL (including Aurora, RDS, Supabase, Neon)
31	- Snowflake
32	- BigQuery (Google Cloud)
33	- Redshift (Amazon)
34	- Databricks SQL
35	- MySQL (including Aurora MySQL, PlanetScale)
36	- SQL Server (Microsoft)
37	- DuckDB
38	- SQLite
39	- Other (ask for specifics)
40
41	Remember the dialect for future queries in the same session.
42
43	### 3. Discover Schema (If Warehouse Connected)
44
45	If a data warehouse MCP server is connected:
46
47	1. Search for relevant tables based on the user's description
48	2. Inspect column names, types, and relationships
49	3. Check for partitioning or clustering keys that affect performance
50	4. Look for pre-built views or materialized views that might simplify the query
51
52	### 4. Write the Query
53
54	Follow these best practices:
55
56	Structure:
57	- Use CTEs (WITH clauses) for readability when queries have multiple logical steps
58	- One CTE per logical transformation or data source
59	- Name CTEs descriptively (e.g., `daily_signups`, `active_users`, `revenue_by_product`)
60
61	Performance:
62	- Never use `SELECT *` in production queries -- specify only needed columns
63	- Filter early (push WHERE clauses as close to the base tables as possible)
64	- Use partition filters when available (especially date partitions)
65	- Prefer `EXISTS` over `IN` for subqueries with large result sets
66	- Use appropriate JOIN types (don't use LEFT JOIN when INNER JOIN is correct)
67	- Avoid correlated subqueries when a JOIN or window function works
68	- Be mindful of exploding joins (many-to-many)
69
70	Readability:
71	- Add comments explaining the "why" for non-obvious logic
72	- Use consistent indentation and formatting
73	- Alias tables with meaningful short names (not just `a`, `b`, `c`)
74	- Put each major clause on its own line
75
76	Dialect-specific optimizations:
77	- Apply dialect-specific syntax and functions (see `sql-queries` skill for details)
78	- Use dialect-appropriate date functions, string functions, and window syntax
79	- Note any dialect-specific performance features (e.g., Snowflake clustering, BigQuery partitioning)
80
81	### 5. Present the Query
82
83	Provide:
84
85	1. The complete query in a SQL code block with syntax highlighting
86	2. Brief explanation of what each CTE or section does
87	3. Performance notes if relevant (expected cost, partition usage, potential bottlenecks)
88	4. Modification suggestions -- how to adjust for common variations (different time range, different granularity, additional filters)
89
90	### 6. Offer to Execute
91
92	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.
93
94	## Examples
95
96	Simple aggregation:
97	```
98	/write-query Count of orders by status for the last 30 days
99	```
100
101	Complex analysis:
102	```
103	/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
104	```
105
106	Performance-critical:
107	```
108	/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.
109	```
110
111	## Tips
112
113	- Mention your SQL dialect upfront to get the right syntax immediately
114	- If you know the table names, include them -- otherwise Claude will help you find them
115	- Specify if you need the query to be idempotent (safe to re-run) or one-time
116	- For recurring queries, mention if it should be parameterized for date ranges

People who liked this also viewed

6 picks

Type