Sql analytics

Skill shinzoxD/knackbox/skills/data/sql-analytics

Curated, auditable, benchmark-ready Agent Skills library for Claude Code, Codex, OpenCode, Cursor, and more.

Install

npx -y skills add shinzoxD/knackbox --skill sql-analytics

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

28 days oldThe repository was created 28 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Write analytical SQL for warehouses and BI questions with correct grain and caveats. Use whenever the user asks for warehouse SQL, BigQuery, Snowflake, Redshift, DuckDB analytics, funnel metrics in SQL, or reporting joins — as opposed to OLTP query performance tuning alone.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

1.7 KB, 284 tokens by cl100k_base, as published. Nobody here has run it

SQL Analytics

Analytical SQL answers a question at a stated grain. Wrong grain is the most common way to ship a wrong dashboard.

Workflow

Restate the question, metric definition, time window, and grain.
List tables/columns needed; note joins that fan out.
Write readable SQL (CTEs per logical step).
Qualify dialect functions (date_trunc vs DATE_TRUNC, etc.).
Validate with checks (totals, null rates, distinct counts).
Caveats: delayed events, timezone, deletion policy.

Output format

## Question
…

## Metric definition
…

## SQL
```sql
-- dialect: …

Validation queries

…

Caveats

…


## Rules

1. State grain on every result set ("one row per user-day").
2. Prevent fan-out double counting (pre-aggregate before join).
3. Timezone: store/convert explicitly.
4. Do not invent tables; ask or mark assumptions.
5. Prefer deterministic sorts for "top N".
6. Cost: partition/cluster filters first on large fact tables.

## Edge cases

- **Funnel:** same user universe per step; watch survival bias.
- **SCD/dimensions:** effective dates for attributes.
- **PII:** aggregate; avoid selecting raw emails unless required.