mirror of
https://github.com/phuryn/pm-skills.git
synced 2026-06-10 21:44:56 +03:00
Pawel Huryn
85 lines
2.8 KiB
Markdown
85 lines
2.8 KiB
Markdown
---
|
|
description: Generate SQL queries from natural language — supports BigQuery, PostgreSQL, MySQL, and more
|
|
argument-hint: "<what you want to know, in plain English>"
|
|
---
|
|
|
|
# /write-query -- SQL Query Generator
|
|
|
|
Describe what data you need in plain English and get an optimized SQL query. Supports multiple dialects and can read your schema from uploaded files.
|
|
|
|
## Invocation
|
|
|
|
```
|
|
/write-query Show me daily active users for the last 30 days, broken down by plan tier
|
|
/write-query Find users who signed up last month but never completed onboarding
|
|
/write-query [upload a schema diagram] What's the conversion rate from trial to paid by cohort?
|
|
```
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Understand the Question
|
|
|
|
Parse the user's natural language request to identify:
|
|
- What data is being requested (metrics, dimensions, filters)
|
|
- Time range and granularity
|
|
- Grouping and ordering preferences
|
|
- Output expectations (raw data, aggregated, ranked)
|
|
|
|
### Step 2: Determine Schema
|
|
|
|
If a schema is available (uploaded diagram, DDL, or description):
|
|
- Map the request to specific tables and columns
|
|
- Identify necessary joins
|
|
|
|
If no schema is provided:
|
|
- Ask for the database type (BigQuery, PostgreSQL, MySQL, etc.)
|
|
- Infer a reasonable schema from the question and ask the user to confirm
|
|
- Use common SaaS data model conventions as defaults
|
|
|
|
### Step 3: Generate Query
|
|
|
|
Apply the **sql-queries** skill:
|
|
|
|
- Write the SQL query in the correct dialect
|
|
- Optimize for readability and performance
|
|
- Include comments explaining key logic
|
|
- Add CTEs for complex queries to improve readability
|
|
- Handle edge cases (NULLs, timezone considerations, duplicate handling)
|
|
|
|
### Step 4: Present and Iterate
|
|
|
|
```
|
|
## SQL Query: [What It Does]
|
|
|
|
**Dialect**: [BigQuery / PostgreSQL / MySQL / etc.]
|
|
**Tables used**: [list]
|
|
|
|
### Query
|
|
[SQL code block with comments]
|
|
|
|
### What This Returns
|
|
[Description of the output: columns, rows, expected result shape]
|
|
|
|
### Assumptions
|
|
- [Schema assumptions made]
|
|
- [Business logic assumptions]
|
|
|
|
### Notes
|
|
- [Performance considerations for large datasets]
|
|
- [Edge cases handled or flagged]
|
|
```
|
|
|
|
Offer:
|
|
- "Want me to **modify this** — add filters, change grouping, extend the time range?"
|
|
- "Should I **create a companion query** for a related metric?"
|
|
- "Want me to **build a dashboard** around this query?"
|
|
- "Need a **cohort analysis** version of this?"
|
|
|
|
## Notes
|
|
|
|
- Always include comments in the SQL — PMs share queries with analysts who need to understand intent
|
|
- Default to readable over clever — CTEs over nested subqueries
|
|
- Flag queries that might be slow on large datasets and suggest optimization
|
|
- If the request is ambiguous (e.g., "active users"), ask the user to define the metric precisely
|
|
- Offer to generate the query in multiple dialects if the user is unsure which database they're using
|