Data and analytics pack reference

Every skill in the Data and analytics pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.

For analysts and the people who rely on their numbers: review SQL for the bugs that quietly inflate a figure, and spec dashboards around a decision instead of every chart that was easy to make.

Skills

dashboard-spec

Spec a dashboard before anyone builds it — the audience and the decision it serves, the questions in priority order, one chart per question with the chart type and why, the defined metric behind each chart, filters, refresh cadence and freshness SLA, and a list of what is deliberately left off, with vanity metrics cut.

Tier standard · v0.1.1 · SKILL.md · skill page

Use it when the user says "spec a dashboard", "what should go on our KPI dashboard", "the BI team needs requirements for a dashboard", "our dashboard has 40 charts and nobody uses it", or "design the exec dashboard".

A good result:

• A one-sentence decision statement names who decides what, and how often.
• At most seven questions, in priority order, each with the action a bad answer triggers.
• One chart per question, with a type and a reason. No chart without a question.
• Every chart names a metric by its defined name, or flags it undefined as a build blocker.
• Every number tile carries a comparison.
• Filters are four or fewer, have defaults, and never fan out a metric.
• Refresh cadence matches the decision cadence, with a freshness SLA and a visible stale-data behaviour.
• A cut list exists, with a reason for each item, and vanity metrics are on it.
• Nothing is invented. Metrics, targets and data sources not given are marked [assumption] or undefined.

Not for:

• Defining how one metric is calculated (formula, filters, timezone) — that's the metric owner's call; this skill flags the gap, it doesn't fill it
• Choosing which metric judges a feature, with targets and a decision rule — that's success-metrics
• Service health dashboards, SLOs and alerting — that's observability-plan
• A report on AI tool usage from telemetry logs — that's ai-usage-report

sql-review

Review a SQL query for correctness first and performance second — join fan-out inflating sums, NULL traps in filters and NOT IN, timezone and date-boundary errors, integer division, DISTINCT hiding a bad join, window-frame defaults, implicit casts, non-sargable predicates and missing partition filters — with each finding tied to a line, the wrong number it produces, and corrected SQL for the named dialect.

Tier heavy · v0.1.2 · SKILL.md · skill page

Use it when the user pastes a query and asks "is this right", "review my SQL", "why is this number too high", "check this before it goes in the dashboard", or "make this query faster".

Needs: Python 3 for its scripts (standard library only).

A good result:

• Correctness findings come before performance findings, and a query with an open 🟥 is never given performance advice as its headline.
• Every finding names a line, the wrong result it produces, and corrected SQL. A finding without a fix is a complaint.
• The wrong result is stated in business terms, such as "refund rate always shows 0", not as "integer division issue".
• Fixes are in the user's dialect. No SAFE_DIVIDE in a Postgres review, no ::numeric in BigQuery.
• Join fan-out is checked for every join, even when the lint is clean.
• A full corrected query is provided, plus verification queries that would show whether the fix worked.
• Lint hits are triaged, not pasted. Each one is confirmed or dismissed with a reason.
• Nothing about the schema is invented. Key uniqueness, column types and timezones not given are listed as assumptions with a query to check each.

Not for:

• Deciding what a metric should mean (formula, filters, owner) — that's the metric owner's call; this skill checks that SQL computes it correctly
• Designing tables, keys and indexes from access patterns — this reviews queries against a schema, not the schema
• Agreeing a dataset's schema, quality SLAs and change policy with its consumers — that's data-contract
• General application code review, including SQL built in application code for security — that's pre-merge-review

Loops

measure

Take a dashboard request to a spec a BI developer can build on numbers people can defend: the decision it serves and one chart per question, every metric defined, the SQL behind each metric reviewed for the bugs that quietly inflate a figure, and the metric owner's sign-off on each definition before anything is built.

Cap: 3 returns before BLOCKED. LOOP.md

Included from core

Installed with this pack. Details: Core pack reference.

• brief-intake: Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake.
• context-graph: Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist.
• council-review: Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council."
• doc-critique: Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each.
• output-hygiene: Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite.

Edit this page on GitHub · View source