{
  "description": "For analysts and the people who rely on their numbers: define a metric once so everyone gets the same figure, review SQL for the bugs that quietly inflate it, and spec dashboards around a decision instead of every chart that was easy to make.",
  "display_name": "Data and analytics",
  "keywords": ["metrics", "sql", "dashboard", "semantic-layer", "dbt", "bi", "analytics"],
  "links": {
    "documentation": "https://sananthanarayan.github.io/skilldrop/packs/data-analytics/"
  },
  "maintainers": [
    {
      "name": "sananthanarayan"
    }
  ],
  "first-value": {
    "audience-posture": "technical",
    "prerequisites": ["A SQL query whose number you need to trust, and the database it runs on"],
    "starter-task": "Check a query before its number goes into a report",
    "starter-prompt": "Review this Postgres query before it goes into the finance dashboard. One row per region; customers.customer_id is unique and an order has many order_items. Finance reports in New York time.\n\nSELECT c.region, SUM(o.amount_usd) AS revenue_usd\nFROM orders o\nJOIN customers c ON c.customer_id = o.customer_id\nJOIN order_items oi ON oi.order_id = o.order_id\nWHERE o.created_at BETWEEN '2026-09-01' AND '2026-09-30'\nGROUP BY c.region;",
    "verification": "sql-review opens with a verdict, flags the order_items join as multiplying revenue and the BETWEEN as losing 30 September, gives a corrected query with New York boundaries, and lists verification queries to prove the fix.",
    "recovery": "If the review jumps to indexes before correctness, ask for it by name (\"use sql-review\"). If it guesses the database, tell it which one: integer division and timezone functions differ between engines."
  },
  "requires": ["core"],
  "journey": {
    "when": "A number matters (a board metric, a finance figure, a team KPI) and people either disagree about it or are about to build a dashboard on it.",
    "you_bring": [
      "the metric name and the question it answers",
      "the tables it comes from, and any SQL or dashboard already computing it",
      "who reads it and what they decide",
      "the database engine (Postgres, BigQuery, Snowflake, …)"
    ],
    "steps": [
      {
        "skill": "metric-definition",
        "you_do": "Give it the metric, the sources, and any existing SQL.",
        "you_get": "One written definition: exact formula, grain, window and timezone, exclusions with predicates, allowed dimensions, edge cases, owner, reference SQL and sanity checks.",
        "decide": "Confirm the open decisions (timezone, exclusions, lock period) with the metric's owner."
      },
      {
        "skill": "sql-review",
        "you_do": "Run it on the definition's reference SQL, or on any query that already reports the number.",
        "you_get": "A verdict and line-by-line findings, each with the wrong result and corrected SQL, plus the full corrected query and verification queries.",
        "decide": "Certify the metric, or fix the SQL and review again."
      },
      {
        "skill": "dashboard-spec",
        "you_do": "Give it the audience, the decision and the list of requested charts.",
        "you_get": "A one-page spec: questions in priority order, one chart per question built on your defined metrics, filters, freshness SLA, layout, and a cut list."
      },
      {
        "skill": "doc-critique",
        "you_do": "Run it on the metric spec or dashboard spec before sharing it with the BI team.",
        "you_get": "A verdict and severity-tagged findings with a fix for each.",
        "decide": "Hand the spec to the builder, or revise it."
      }
    ],
    "you_end_with": "A certified metric definition with reviewed reference SQL, and a dashboard spec a BI developer can build without guessing."
  }
}