From pm-analytics
Write or explain SQL and analytics queries for product data. Use when a PM needs to pull product metrics, understand user behavior, or validate analytics without waiting for a data analyst.
How this command is triggered — by the user, by Claude, or both
Slash command
/pm-analytics:data-query [write | explain] [query description or SQL]The summary Claude sees in its command listing — used to decide when to auto-load this command
Writes or explains SQL and analytics queries for product use cases. ## Routing - **`write [description]`**: write a query for the described question. - **`explain [SQL]`**: explain what an existing query does in plain language. - **No argument**: ask questions below first. ## Questions (no argument) ## Output (write) **Query: [Description]** **What this returns** Plain-language description of the result set — columns, rows, and what the numbers represent. **How to interpret** What to look for in the results. Common gotchas or caveats. **Variations** 1–2 common follow-up queries ...
Writes or explains SQL and analytics queries for product use cases.
write [description]: write a query for the described question.explain [SQL]: explain what an existing query does in plain language.Before I write the query, a few questions:
1. Write a new query or explain an existing one?
2. What question are you trying to answer?
3. What tables or data do you have access to? (schema, table names, key columns)
4. What analytics tool or SQL dialect? (BigQuery / PostgreSQL / Redshift / Snowflake / Amplitude / Mixpanel)
5. Any time range or filter constraints?
Answer as many as you can.
Query: [Description]
-- [Brief comment on what this query answers]
SELECT
...
FROM
...
WHERE
...
GROUP BY
...
ORDER BY
...
What this returns Plain-language description of the result set — columns, rows, and what the numbers represent.
How to interpret What to look for in the results. Common gotchas or caveats.
Variations 1–2 common follow-up queries (segment by cohort, filter to specific plan, etc.).
Query explanation: [source]
What this query does in plain English:
Potential issues Performance concerns, logic edge cases, or results that might surprise you.
Queries should be readable — comments where the logic isn't obvious, CTEs instead of deeply nested subqueries. A query a PM can read is a query a PM can modify.
npx claudepluginhub songd-85/pm-ops --plugin pm-analytics