---
id: daily-write-query
name: "write-query"
url: https://skills.yangsir.net/skill/daily-write-query
author: anthropics
domain: ai-data-management-analysis
tags: ["sql", "natural-language", "query-optimization", "data-extraction", "database"]
install_count: 3000
rating: 4.40 (20 reviews)
github: https://github.com/anthropics/knowledge-work-plugins
---

# write-query

> 根据自然语言描述自动生成优化的 SQL 查询，支持复杂联表和聚合操作，无需手写代码即可快速检索数据

**Stats**: 3,000 installs · 4.4/5 (20 reviews)

## Before / After 对比

### SQL 查询编写效率

**Before**:

手动编写 SQL 需要熟悉表结构、字段名和语法规则，复杂查询需要反复调试，一个数据分析需求通常需要 30 分钟完成

**After**:

直接用自然语言描述需求，系统自动生成优化过的 SQL 查询，支持 JOIN、GROUP BY 等复杂操作，2 分钟即可获得可执行的查询语句

| Metric | Before | After | Change |
|---|---|---|---|
| 查询开发时间 | 30分钟 | 2分钟 | -93% |

## Readme

# write-query

# /write-query - Write Optimized SQL

If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](https://github.com/anthropics/knowledge-work-plugins/blob/HEAD/data/skills/write-query/../../CONNECTORS.md).

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

## Usage

```
/write-query <description of what data you need>

```

## Workflow

### 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?

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

### 3. Discover Schema (If Warehouse Connected)

If a data warehouse MCP server is connected:

- Search for relevant tables based on the user's description

- Inspect column names, types, and relationships

- Check for partitioning or clustering keys that affect performance

- Look for pre-built views or materialized views that might simplify the query

### 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)

### 5. Present the Query

Provide:

- **The complete query** in a SQL code block with syntax highlighting

- **Brief explanation** of what each CTE or section does

- **Performance notes** if relevant (expected cost, partition usage, potential bottlenecks)

- **Modification suggestions** -- how to adjust for common variations (different time range, different granularity, additional filters)

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

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

```

## 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

Weekly Installs293Repository[anthropics/know…-plugins](https://github.com/anthropics/knowledge-work-plugins)GitHub Stars10.6KFirst SeenMar 13, 2026Security Audits[Gen Agent Trust HubPass](/anthropics/knowledge-work-plugins/write-query/security/agent-trust-hub)[SocketPass](/anthropics/knowledge-work-plugins/write-query/security/socket)[SnykPass](/anthropics/knowledge-work-plugins/write-query/security/snyk)Installed oncodex279gemini-cli277opencode276cursor276github-copilot275amp275

---
*Source: https://skills.yangsir.net/skill/daily-write-query*
*Markdown mirror: https://skills.yangsir.net/api/skill/daily-write-query/markdown*