SQL-запрос по описанию словами

Превращает описание нужных данных обычными словами в готовый SQL-запрос под ваш диалект: Postgres, Snowflake, BigQuery и другие.

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Превращает описание нужных данных обычными словами в готовый SQL-запрос под ваш диалект: Postgres, Snowflake, BigQuery и другие.
Когда брать: Когда нужно получить данные из базы, но писать запрос вручную долго или сложно, и нужен быстрый и читаемый SQL.
Когда не брать: Если нет базы данных или хранилища, к которым можно обращаться запросами.
Пример запроса: Напиши запрос: количество заказов по статусам за последние 30 дней, у нас PostgreSQL.
Нужно подключить: хранилище данных

Входит в плагин data. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Нажмите «Скачать на русском» и сохраните архив.
В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
Включите скилл переключателем.

Для терминала

Распакуйте архив и положите папку write-query в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: write-query
description: Напиши оптимизированный SQL для своего диалекта по лучшим практикам. Используй, когда нужно перевести потребность в данных, сформулированную обычными словами, в SQL, собрать запрос из нескольких CTE с соединениями и агрегациями, оптимизировать запрос к большой партиционированной таблице или получить синтаксис конкретного диалекта: Snowflake, BigQuery, Postgres и других.
argument-hint: "<description of what data you need>"
---

/write-query - Написание оптимизированного SQL

Если встретишь незнакомые подстановки или нужно проверить, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).

Напиши SQL-запрос по описанию на обычном языке, оптимизированный под конкретный диалект SQL пользователя и соответствующий лучшим практикам.

Использование

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

Рабочий процесс

1. Пойми запрос

Разбери описание пользователя и определи:

Столбцы результата: какие поля должны войти в результат?
Фильтры: какие условия ограничивают данные (периоды, сегменты, статусы)?
Агрегации: нужны ли GROUP BY, подсчёты, суммы, средние?
Соединения: нужно ли объединять несколько таблиц?
Сортировка: как упорядочить результаты?
Ограничения: нужен ли топ-N или выборка?

2. Определи диалект SQL

Если диалект SQL пользователя ещё неизвестен, спроси, каким он пользуется:

PostgreSQL (включая Aurora, RDS, Supabase, Neon)
Snowflake
BigQuery (Google Cloud)
Redshift (Amazon)
Databricks SQL
MySQL (включая Aurora MySQL, PlanetScale)
SQL Server (Microsoft)
DuckDB
SQLite
Другой (уточни детали)

Запомни диалект для следующих запросов в той же сессии.

3. Изучи схему (если подключено хранилище)

Если подключён MCP-сервер хранилища данных:

Найди нужные таблицы по описанию пользователя
Изучи названия столбцов, типы и связи
Проверь ключи партиционирования и кластеризации, влияющие на производительность
Поищи готовые представления или материализованные представления, которые могут упростить запрос

4. Напиши запрос

Следуй этим лучшим практикам:

Структура:

Используй CTE (конструкции WITH) для читаемости, если у запроса несколько логических шагов
Одна CTE на каждое логическое преобразование или источник данных
Давай CTE понятные имена (например, daily_signups, active_users, revenue_by_product)

Производительность:

Никогда не используй SELECT * в рабочих запросах — указывай только нужные столбцы
Фильтруй как можно раньше (ставь условия WHERE как можно ближе к базовым таблицам)
Используй фильтры по партициям, когда они есть (особенно по датам)
Для подзапросов с большим результатом предпочитай EXISTS вместо IN
Используй подходящие типы JOIN (не применяй LEFT JOIN, где нужен INNER JOIN)
Избегай коррелированных подзапросов, когда подойдёт JOIN или оконная функция
Следи за «взрывными» соединениями (многие ко многим)

Читаемость:

Добавляй комментарии, объясняющие «почему», для неочевидной логики
Используй единые отступы и форматирование
Давай таблицам осмысленные короткие псевдонимы (а не просто a, b, c)
Размещай каждую основную конструкцию на отдельной строке

Оптимизации под диалект:

Применяй синтаксис и функции конкретного диалекта (подробности — в скилле sql-queries)
Используй функции дат, строковые функции и оконный синтаксис, подходящие диалекту
Отметь особенности производительности, свойственные диалекту (например, кластеризация в Snowflake, партиционирование в BigQuery)

5. Представь запрос

Дай:

Полный запрос в блоке кода SQL с подсветкой синтаксиса
Краткое объяснение, что делает каждая CTE или раздел
Заметки о производительности, если уместно (ожидаемая стоимость, использование партиций, возможные узкие места)
Предложения по изменению — как подстроить запрос под типичные варианты (другой период, другая детализация, дополнительные фильтры)

6. Предложи выполнить запрос

Если хранилище данных подключено, предложи выполнить запрос и проанализировать результаты. Если пользователь хочет выполнить запрос сам, запрос готов к копированию.

Примеры

Простая агрегация:

/write-query Количество заказов по статусам за последние 30 дней

Сложный анализ:

/write-query Анализ удержания когорт — сгруппируй пользователей по месяцу регистрации, затем покажи, какой процент остаётся активным (совершил хотя бы одно событие) через 1, 3, 6 и 12 месяцев после регистрации

Когда критична производительность:

/write-query У нас таблица событий на 500 млн строк, партиционированная по дате. Найди 100 пользователей с наибольшим числом событий за последние 7 дней и тип их последнего события.

Советы

Сразу укажи свой диалект SQL, чтобы сразу получить правильный синтаксис
Если знаешь названия таблиц, укажи их — иначе Claude поможет их найти
Укажи, должен ли запрос быть идемпотентным (безопасным для повторного запуска) или одноразовым
Для повторяющихся запросов скажи, нужна ли параметризация по диапазонам дат

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/data/skills/write-query, лицензия Apache-2.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.
argument-hint: "<description of what data you need>"
---

# /write-query - Write Optimized SQL

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../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:

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

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

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)

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

Источник: anthropics/knowledge-work-plugins / data / write-query ↗. Ссылка проверена 2026-10-10.

---
name: write-query
description: Напиши оптимизированный SQL для своего диалекта по лучшим практикам. Используй, когда нужно перевести потребность в данных, сформулированную обычными словами, в SQL, собрать запрос из нескольких CTE с соединениями и агрегациями, оптимизировать запрос к большой партиционированной таблице или получить синтаксис конкретного диалекта: Snowflake, BigQuery, Postgres и других.
argument-hint: "<description of what data you need>"
---

# /write-query - Написание оптимизированного SQL

> Если встретишь незнакомые подстановки или нужно проверить, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).

Напиши SQL-запрос по описанию на обычном языке, оптимизированный под конкретный диалект SQL пользователя и соответствующий лучшим практикам.

## Использование

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

## Рабочий процесс

### 1. Пойми запрос

Разбери описание пользователя и определи:

- **Столбцы результата**: какие поля должны войти в результат?
- **Фильтры**: какие условия ограничивают данные (периоды, сегменты, статусы)?
- **Агрегации**: нужны ли GROUP BY, подсчёты, суммы, средние?
- **Соединения**: нужно ли объединять несколько таблиц?
- **Сортировка**: как упорядочить результаты?
- **Ограничения**: нужен ли топ-N или выборка?

### 2. Определи диалект SQL

Если диалект SQL пользователя ещё неизвестен, спроси, каким он пользуется:

- **PostgreSQL** (включая Aurora, RDS, Supabase, Neon)
- **Snowflake**
- **BigQuery** (Google Cloud)
- **Redshift** (Amazon)
- **Databricks SQL**
- **MySQL** (включая Aurora MySQL, PlanetScale)
- **SQL Server** (Microsoft)
- **DuckDB**
- **SQLite**
- **Другой** (уточни детали)

Запомни диалект для следующих запросов в той же сессии.

### 3. Изучи схему (если подключено хранилище)

Если подключён MCP-сервер хранилища данных:

1. Найди нужные таблицы по описанию пользователя
2. Изучи названия столбцов, типы и связи
3. Проверь ключи партиционирования и кластеризации, влияющие на производительность
4. Поищи готовые представления или материализованные представления, которые могут упростить запрос

### 4. Напиши запрос

Следуй этим лучшим практикам:

**Структура:**
- Используй CTE (конструкции WITH) для читаемости, если у запроса несколько логических шагов
- Одна CTE на каждое логическое преобразование или источник данных
- Давай CTE понятные имена (например, `daily_signups`, `active_users`, `revenue_by_product`)

**Производительность:**
- Никогда не используй `SELECT *` в рабочих запросах — указывай только нужные столбцы
- Фильтруй как можно раньше (ставь условия WHERE как можно ближе к базовым таблицам)
- Используй фильтры по партициям, когда они есть (особенно по датам)
- Для подзапросов с большим результатом предпочитай `EXISTS` вместо `IN`
- Используй подходящие типы JOIN (не применяй LEFT JOIN, где нужен INNER JOIN)
- Избегай коррелированных подзапросов, когда подойдёт JOIN или оконная функция
- Следи за «взрывными» соединениями (многие ко многим)

**Читаемость:**
- Добавляй комментарии, объясняющие «почему», для неочевидной логики
- Используй единые отступы и форматирование
- Давай таблицам осмысленные короткие псевдонимы (а не просто `a`, `b`, `c`)
- Размещай каждую основную конструкцию на отдельной строке

**Оптимизации под диалект:**
- Применяй синтаксис и функции конкретного диалекта (подробности — в скилле `sql-queries`)
- Используй функции дат, строковые функции и оконный синтаксис, подходящие диалекту
- Отметь особенности производительности, свойственные диалекту (например, кластеризация в Snowflake, партиционирование в BigQuery)

### 5. Представь запрос

Дай:

1. **Полный запрос** в блоке кода SQL с подсветкой синтаксиса
2. **Краткое объяснение**, что делает каждая CTE или раздел
3. **Заметки о производительности**, если уместно (ожидаемая стоимость, использование партиций, возможные узкие места)
4. **Предложения по изменению** — как подстроить запрос под типичные варианты (другой период, другая детализация, дополнительные фильтры)

### 6. Предложи выполнить запрос

Если хранилище данных подключено, предложи выполнить запрос и проанализировать результаты. Если пользователь хочет выполнить запрос сам, запрос готов к копированию.

## Примеры

**Простая агрегация:**
```
/write-query Количество заказов по статусам за последние 30 дней
```

**Сложный анализ:**
```
/write-query Анализ удержания когорт — сгруппируй пользователей по месяцу регистрации, затем покажи, какой процент остаётся активным (совершил хотя бы одно событие) через 1, 3, 6 и 12 месяцев после регистрации
```

**Когда критична производительность:**
```
/write-query У нас таблица событий на 500 млн строк, партиционированная по дате. Найди 100 пользователей с наибольшим числом событий за последние 7 дней и тип их последнего события.
```

## Советы

- Сразу укажи свой диалект SQL, чтобы сразу получить правильный синтаксис
- Если знаешь названия таблиц, укажи их — иначе Claude поможет их найти
- Укажи, должен ли запрос быть идемпотентным (безопасным для повторного запуска) или одноразовым
- Для повторяющихся запросов скажи, нужна ли параметризация по диапазонам дат

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/data/skills/write-query, лицензия Apache-2.0. Изменения: перевод на русский язык.