All teams / Data

Data

Write SQL, visualize, validate, ship dashboards, interpret without bullshit.

Data work splits roughly three ways: writing SQL, understanding what it returned, and explaining the result. Pace handles all three. Connect your warehouse once and /data:write-query learns your schema. Use /data:validate-analysis before sharing a conclusion; it has caught Simpson's-paradox-shaped errors more than once.

Plugins to install

Pick from this set for the role. Primary plugins are essential; companions multiply value.

  • data primary

    SQL drafting, visualization, statistical validation, dashboards, anomaly interpretation.

    claude plugin install data@pace
  • engineering companion

    When data questions overflow into pipeline or schema territory.

    claude plugin install engineering@pace
  • finance companion

    Variance analysis and financial-system queries lean on data muscle.

    claude plugin install finance@pace

Connectors to set up

Claude prompts to authorize each one the first time a relevant skill fires. You only do this once per project.

  • Snowflake
  • Databricks
  • BigQuery
  • Hex
  • Amplitude
  • Jira

Workflows

Common ways teams use these plugins day to day. Each one is a starting point; adapt the prompt to your context.

  • Write SQL from intent

    Describe what you want; get SQL back, sized to your schema. Connecting a warehouse means it can also run it and return results.

    /data:write-query monthly active users by plan tier, last 6 months
  • Visualize results

    Suggests the right chart type for a result set and generates the visualization (Hex notebook, plot code, or chart spec).

    /data:visualize this query result
  • Validate an analysis

    Pre-flight check before sharing a conclusion. Looks for confounds, sampling issues, base-rate mistakes, Simpson's paradox shapes.

    /data:validate-analysis my conclusion that conversion improved 12% in Q3
  • Statistical test

    Runs the right test (chi-square, t-test, mann-whitney) and reports significance, effect size, and what it actually means in business terms.

    /data:statistical-test on A/B results from last sprint
  • Build a dashboard

    Generates a dashboard spec (Hex, Looker, or Mode-compatible) from a set of queries.

    /data:dashboard for weekly product health metrics
  • Interpret an anomaly

    Given a chart or metric drop, generates plausible explanations ranked by likelihood and what data would distinguish them.

    /data:interpret this drop in DAU last Tuesday

Tips & tricks

Field-tested patterns from teams that have already shipped a quarter or two on these plugins.

  • Always validate before sharing

    /data:validate-analysis catches the errors that get spotted by the audience in the meeting. Cheap insurance.

  • Connect the warehouse first

    Without a connector, /data:* writes SQL but can't run it. With one, the workflow is interactive.

  • Document queries you keep

    /data:document-query before saving SQL to your team library. Future-you appreciates context.

  • Use the three-step rhythm

    For exploratory: /data:write-query → /data:visualize → /data:interpret. Quick, surprisingly thorough.

  • Pair with engineering for perf

    When the query is slow, hand off via /engineering:code-review of the EXPLAIN plan.

  • Statistical tests are not optional for A/B

    /data:statistical-test instead of eyeballing two means. It tells you whether the effect is real.

See also