skilldrop-cli 0.16.11 → 0.16.13

package/packs/data-analytics/skills/metric-definition/evals/evals.json

@@ -1,79 +0,0 @@
-{
-  "skill_name": "metric-definition",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "Product and sales at Northwind both report 'active customers' and the numbers never match. Product counts any account with a login in the last 30 days; sales counts accounts with a paid subscription. We use BigQuery: `analytics.logins` (account_id, login_ts TIMESTAMP), `billing.subscriptions` (account_id, status, plan, started_at, ended_at), and `crm.accounts` (account_id, segment, is_internal BOOL). Leadership wants one monthly number for the board, reported in London time. Write the definition.",
-      "assertions": [
-        "Splits the two meanings into separately named metrics (for example login-based and paid-subscription-based) instead of one name with a footnote, and states which one the board number uses or lists it as an open decision",
-        "Writes the formula as an aggregation over the named columns, using COUNT(DISTINCT account_id)",
-        "States the time column, a half-open window and the timezone as Europe/London",
-        "States that the metric is not additive and that monthly or segment values must be recomputed, not summed",
-        "Excludes internal accounts with an explicit predicate on crm.accounts.is_internal and gives a reason",
-        "Provides reference SQL in BigQuery syntax that converts the window boundaries to Europe/London",
-        "Includes at least three runnable sanity checks, including a known-answer fixture or a reconciliation with billing",
-        "Does not invent tables, columns or an owner not given in the prompt; anything assumed is tagged [assumption] and listed under open decisions"
-      ]
-    },
-    {
-      "id": 2,
-      "held_out": "2026-10-05",
-      "prompt": "Finance and CX keep turning up to the Monday meeting with different refund rates and it's getting silly. I've pasted the Slack thread into thread.md and the table descriptions into tables.md. Can you write down one proper definition of refund rate that we can all use, with the SQL? We're on Postgres.",
-      "assertions": [
-        "It separates the share of orders refunded from the share of revenue refunded as two differently named measures, or picks one as 'refund rate' and names the other as a separate measure; it does not blend them into one formula",
-        "It points out that 312 refunded orders out of 7,480 is about 4.2%, not the 4.6% quoted in the thread",
-        "The order-based SQL counts each refunded order once (COUNT DISTINCT on order_id, EXISTS, or refunds aggregated per order before joining), so orders with several refund rows are not double-counted",
-        "It states one rule for which month a refund belongs to (the order's month or the refund's month) and says what happens to a February order refunded in March",
-        "It says a single money-based rate across both stores cannot be computed from these tables as they stand because there is no exchange-rate data, and it does not invent an exchange rate or an exchange-rate table",
-        "Test orders are excluded with a condition on orders.is_test, and staff orders are flagged as not identifiable from the listed columns; it does not use a staff flag column that does not exist",
-        "Month boundaries are set in UK time (Europe/London) against timestamps stored in UTC",
-        "It lists whether cancelled orders count in the denominator and who owns the metric as open decisions, without naming an owner the thread did not name"
-      ]
-    },
-    {
-      "id": 3,
-      "held_out": "2026-10-05",
-      "prompt": "need a proper definition of 'time to first response' for our support team. we use a helpdesk tool and I can export tickets to a spreadsheet. my boss wants it on the weekly report. there's 8 agents. not sure if weekends should count, we don't work them",
-      "assertions": [
-        "It delivers a written definition in the reply and does not stop at a list of questions",
-        "It defines the start and the end of the clock (ticket created to the first reply from a human agent) and says automatic acknowledgement emails do not count as the first response, or flags that as a decision",
-        "Whether weekends and out-of-hours time count is given as an open decision with a recommended default or with both versions described; it is not decided silently",
-        "It says which statistic goes on the report (median, mean or a percentile), not just 'average' left undefined",
-        "It says how tickets that have had no reply yet when the report is run are treated",
-        "It says which week a ticket is counted in (the week it was created or the week it was answered)",
-        "Any export column names it uses are marked as assumed, since no export layout was given",
-        "It does not state a response-time target or SLA figure as the team's own, since none was given"
-      ]
-    },
-    {
-      "id": 4,
-      "held_out": "2026-10-06",
-      "prompt": "Ops and customer care at Tarn Valley Heating both report first-time fix rate and they're miles apart. The Slack thread is in thread.md and the tables are in tables.md (we're on Snowflake). The FD wants one number for the board pack, ready on the 1st of each month, shown next to last September. Can you write the definition — one page, with the SQL underneath?",
-      "assertions": [
-        "It points out that 3,912 out of 4,830 is 81%, not the 84% quoted in the thread",
-        "The definition counts a repair as not fixed first time when there is a return visit within a stated number of days, and does not rely only on the engineer's follow_up_required flag",
-        "It explains the gap between the two teams' figures: 630 of the 3,912 repairs with no follow-up flag had a return visit within 30 days, leaving 3,282 (68%)",
-        "A return visit is counted whether it was logged as a 'recall' or as a new 'repair', and recall visits are not themselves added to the denominator as fresh repairs",
-        "It says the month's figure cannot be final on the 1st of the next month because the return window has not yet run for late-month repairs, and proposes a provisional figure, a lag or a shorter window",
-        "It says a like-for-like comparison with September 2025 is not possible by appliance because appliance_id is empty before 3 March 2026, and says what to do instead (match by address for both periods, or mark the comparison as not comparable)",
-        "The SQL uses only the tables and columns listed in tables.md, restricts the denominator to completed repairs, and does not invent a column linking a return visit to its original job",
-        "It leaves the metric owner as an open decision, noting the previous owner left in August, and says whether subcontractor jobs are included"
-      ]
-    },
-    {
-      "id": 5,
-      "held_out": "2026-10-06",
-      "prompt": "I run a coffee subscription box, just me and one part-timer. An investor asked what our monthly churn is and I realised I've never actually defined it. Billing is on Stripe and I keep a Google Sheet of subscribers. September: started the month with 312 subscribers, 21 cancelled, 9 paused (people can pause for a month or two instead of cancelling), 34 new signed up. Can you give me a quick definition I can stick to every month, and the September number for the investor update?",
-      "assertions": [
-        "It delivers a written definition and a September figure in the reply, and does not stop at a list of questions",
-        "The denominator is stated as subscribers active at the start of the month (312), and the 34 new sign-ups are not netted off against cancellations",
-        "It gives September churn on cancellations alone as 21 out of 312, about 6.7%",
-        "It does not decide silently whether pauses count: it states the choice made and gives the figure with pauses included, 30 out of 312, about 9.6%",
-        "It says revenue churn cannot be worked out from what was given because no prices or plan amounts were provided, and it does not invent a price",
-        "It says whether a cancellation is counted in the month the subscriber cancels or the month their paid period ends",
-        "It does not quote an industry-average or benchmark churn figure as fact",
-        "Any Stripe field names or sheet column names it uses are marked as assumed, since none were given"
-      ]
-    }
-  ]
-}

package/packs/data-analytics/skills/metric-definition/evals/files/2/tables.md

@@ -1,42 +0,0 @@
-# Tallow & Thyme: tables (Postgres 15)
-
-All timestamps are `timestamptz`, stored in UTC. The business reports on UK time.
-
-## orders
-
-| Column | Type | Notes |
-|---|---|---|
-| order_id | bigint | primary key |
-| customer_id | bigint | references customers |
-| store | text | 'uk' or 'eu' |
-| currency | text | 'GBP' for the uk store, 'EUR' for the eu store |
-| gross_amount_minor | integer | order total in pence (GBP) or cents (EUR) |
-| placed_at | timestamptz | when the order was placed |
-| status | text | 'placed', 'delivered', 'cancelled' |
-| is_test | boolean | true for orders made by the test harness |
-
-## refunds
-
-| Column | Type | Notes |
-|---|---|---|
-| refund_id | bigint | primary key |
-| order_id | bigint | references orders |
-| amount_minor | integer | in the same currency as the order |
-| reason | text | free text typed by the CX agent |
-| created_at | timestamptz | when the refund was issued |
-
-An order can have more than one refund row: a missing ingredient is refunded, then a second
-problem with the same box is refunded later. About 1 in 9 refunded orders has two or more
-rows.
-
-## customers
-
-| Column | Type | Notes |
-|---|---|---|
-| customer_id | bigint | primary key |
-| email | text | |
-| created_at | timestamptz | |
-
-## Not in the database
-
-There is no exchange-rate table. Finance converts EUR to GBP by hand in a spreadsheet.

package/packs/data-analytics/skills/metric-definition/evals/files/2/thread.md

@@ -1,40 +0,0 @@
-# #ops-metrics, exported 3 March 2026
-
-**Hattie Blum** (CX lead) 09:12
-Feb refund rate is 4.6%. 312 refunded orders out of 7,480 orders.
-
-**Rupert Osei** (Finance) 09:20
-I get 3.5%. £9,870 refunded on £284,300 gross.
-
-**Hattie Blum** 09:24
-Well mine is orders, yours is money. I count an order as refunded if it shows up in the
-refunds table. I go by the date the refund was issued, so that's refunds issued in Feb.
-
-**Rupert Osei** 09:31
-I go by the month the order was placed. If a Feb order gets refunded in March it goes back
-against Feb, that's how the P&L works. Also mine is the UK store only. The EU store is in a
-separate sheet and I convert the euros by hand at whatever the rate is that day, I haven't
-done Feb yet.
-
-**Hattie Blum** 09:33
-Mine is both stores.
-
-**Mina Castellanos** (founder) 09:47
-This is why the Monday meeting goes round in circles. I want ONE refund rate for the whole
-business, both stores, monthly, on UK time. And take out test orders, and staff orders too.
-Staff get free boxes and we refund them through the system so they make it look worse than
-it is.
-
-**Hattie Blum** 09:52
-There's an is_test flag on orders. No idea how you'd spot staff orders though, we just know
-the names.
-
-**Rupert Osei** 09:55
-Do cancelled orders count as orders? I leave them in, they were placed.
-
-**Hattie Blum** 09:58
-I take them out.
-
-**Mina Castellanos** 10:05
-Someone write it down properly please. Who owns it after that, tbd, let's get the definition
-sorted first.

package/packs/data-analytics/skills/metric-definition/evals/files/4/tables.md

@@ -1,32 +0,0 @@
-# Tables (Snowflake, database TARNVALLEY)
-
-## FIELD.JOBS — one row per visit
-| column | type | notes |
-|---|---|---|
-| job_id | NUMBER | primary key |
-| address_id | NUMBER | always filled |
-| appliance_id | NUMBER | NULL for every job before 2026-03-03 |
-| job_type | VARCHAR | 'repair', 'recall', 'annual_service', 'install' |
-| status | VARCHAR | 'completed', 'cancelled', 'no_access' |
-| follow_up_required | BOOLEAN | ticked by the engineer on closing the job |
-| engineer_id | NUMBER | |
-| created_at | TIMESTAMP_NTZ | UK local time, when the job was booked |
-| completed_at | TIMESTAMP_NTZ | UK local time, NULL unless status = 'completed' |
-
-There is no column that links a recall, or any later visit, to the job it follows.
-
-## FIELD.APPLIANCES
-| column | type | notes |
-|---|---|---|
-| appliance_id | NUMBER | primary key |
-| address_id | NUMBER | |
-| make | VARCHAR | |
-| model | VARCHAR | |
-| installed_on | DATE | often NULL |
-
-## FIELD.ENGINEERS
-| column | type | notes |
-|---|---|---|
-| engineer_id | NUMBER | primary key |
-| region | VARCHAR | 'north', 'central', 'coast' |
-| employment_type | VARCHAR | 'employed', 'subcontractor' |

package/packs/data-analytics/skills/metric-definition/evals/files/4/thread.md

@@ -1,31 +0,0 @@
-# #ops-reporting — export, 1–2 October 2026
-
-**Gethin Aldous (Regional Ops Manager), 1 Oct 09:12**
-September first-time fix is in. 3,912 of 4,830 completed repairs closed with no follow-up flag. That's 84%. Best month this year.
-
-**Roisin Fairweather (Customer Care Lead), 1 Oct 09:40**
-We get 68%. 3,282 of 4,830. We only count a repair as fixed if nobody had to go back within 30 days.
-
-**Gethin Aldous, 1 Oct 09:44**
-The engineer ticks follow_up_required when the job needs another visit. That is the record. If they didn't tick it, it was fixed.
-
-**Roisin Fairweather, 1 Oct 09:58**
-They don't tick it when they think it's fixed and it isn't. 630 of your 3,912 had someone back out within 30 days. Those customers rang us, not you.
-And you can't just count recalls either. The contact centre logs about half of the go-backs as a brand new repair instead of a recall, because that's the default in the booking screen.
-
-**Gethin Aldous, 1 Oct 10:03**
-For what it's worth 4,830 already leaves out cancelled and no-access visits. We agree on that at least.
-
-**Nkechi Brandt (BI Analyst), 1 Oct 10:20**
-I pulled both sets of numbers this morning. Two things from the data side:
-- appliance_id has only been filled in since 3 March 2026 when the new engineer app went live. Before that it's NULL and all you have is address_id.
-- Some addresses have more than one appliance (HMOs, small commercial units). So "same address" and "same appliance" are not the same test.
-
-**Owen Prys (Finance Director), 2 Oct 08:15**
-The board pack needs one number, ready on the 1st of each month, with last September next to it for comparison. Subcontractors in or out, I don't mind, just tell me which. And who owns this going forward?
-
-**Gethin Aldous, 2 Oct 08:31**
-It was Marguerite's before she left in August. Nobody has picked it up.
-
-**Roisin Fairweather, 2 Oct 08:40**
-Installs and annual services shouldn't be anywhere near this, by the way. It's a repair measure.

package/packs/data-analytics/skills/metric-definition/examples/refund-rate.md

@@ -1,104 +0,0 @@
-# Worked example: order refund rate
-
-## Input
-
-> Finance says our September refund rate was one number and support says another. Can you write a proper definition? We're on Postgres. Orders are in `orders` (`order_id`, `customer_id`, `created_at` timestamptz, `amount_usd`), refunds in `refunds` (`refund_id`, `order_id`, `status`, `created_at`), and `test_accounts` lists QA customers. Finance reports monthly in New York time. Finance counts an order as refunded if any refund on it went through; support counts refund tickets. The finance analytics lead at Acme owns finance metrics.
-
-No questions asked: the decision (monthly finance reporting), the sources and the owner are all in the prompt. The dispute itself shows the two teams are measuring different things, so the spec splits them.
-
-## Output
-
-# Metric: `order_refund_rate` (v1, draft)
-
-**Business question:** What share of the orders placed in a month had at least one refund go through, by region? Read monthly by finance to track refund exposure.
-**Owner:** Finance analytics lead, Acme finance · **Status:** draft · **Last changed:** 2026-10-01
-
-**Why support's number differs:** support counts refund tickets, which is a different metric (`refund_tickets`, a count of tickets, not a share of orders). An order with two partial refunds is one refunded order here and two tickets there. Both are legitimate; they need separate names.
-
-## Formula
-
-| Part | In words | As an aggregation |
-|---|---|---|
-| Numerator | Orders in the window with at least one refund whose status is not `reversed` | `COUNT(DISTINCT o.order_id)` where a qualifying refund exists |
-| Denominator | Orders created in the window, excluding test accounts | `COUNT(DISTINCT o.order_id)` |
-
-- **Type:** ratio
-- **Unit and format:** %, 1 decimal
-
-## Grain and time
-
-- **Entity:** order
-- **Time column:** `orders.created_at`, so the refund is attributed to the month the order was placed. A September order refunded in October counts toward September.
-- **Window:** calendar month, half-open
-- **Timezone:** `America/New_York`
-- **Partial periods:** the current month is shown and labelled "month to date"
-- **Additivity:** not additive. A quarterly or all-region rate is recomputed from the base rows, never averaged from monthly or regional rates.
-
-## Filters and exclusions
-
-| Exclusion | Predicate | Reason |
-|---|---|---|
-| Test accounts | `NOT EXISTS (SELECT 1 FROM test_accounts t WHERE t.customer_id = o.customer_id)` | QA places real orders in production |
-| Reversed refunds | `r.status IS DISTINCT FROM 'reversed'` | A reversed refund returned no money |
-
-## Dimensions
-
-| Dimension | Source column | Join path | Cardinality | Allowed? |
-|---|---|---|---|---|
-| Region | `customers.region` | `orders.customer_id = customers.customer_id` | many-to-one `[assumption: customer_id unique]` | yes |
-| Product category | `order_items` → `products.category` | through `order_items` | one-to-many: fans out | no. An order with two categories would count in both. |
-
-## Edge cases
-
-| Case | Rule |
-|---|---|
-| Refund with NULL status | Counts as a refund `[assumption]` |
-| Zero orders in a region-month | Rate is NULL, shown blank |
-| Late data | Refunds arrive weeks after the order, so a month's rate keeps rising. The month locks for reporting 60 days after month end `[assumption]`; before that, label it "provisional". |
-| Currency | Not applicable: the metric counts orders, not money |
-| DST | Not applicable at month grain; boundaries are converted to New York time |
-| Duplicate refund rows | Handled: the numerator counts distinct orders |
-
-## Reference SQL (Postgres)
-
-```sql
-WITH base AS (                   -- orders placed in the month, no test accounts
-  SELECT o.order_id, o.customer_id
-  FROM orders o
-  WHERE o.created_at >= TIMESTAMP '2026-09-01' AT TIME ZONE 'America/New_York'
-    AND o.created_at <  TIMESTAMP '2026-10-01' AT TIME ZONE 'America/New_York'
-    AND NOT EXISTS (SELECT 1 FROM test_accounts t WHERE t.customer_id = o.customer_id)
-),
-refunded AS (                    -- one row per order with a qualifying refund
-  SELECT DISTINCT r.order_id
-  FROM refunds r
-  WHERE r.status IS DISTINCT FROM 'reversed'
-)
-SELECT
-  c.region,
-  COUNT(rf.order_id)::numeric / NULLIF(COUNT(*), 0) AS order_refund_rate
-FROM base b
-JOIN customers c      ON c.customer_id = b.customer_id
-LEFT JOIN refunded rf ON rf.order_id = b.order_id
-GROUP BY c.region;
-```
-
-## Sanity checks
-
-1. **Join integrity:** `SELECT COUNT(*) FROM base` equals the sum of per-region order counts from the query above with `COUNT(*)` added. If it's lower, orders without a matching customer are being dropped.
-2. **Bounds:** every region's rate is between 0 and 1, or NULL.
-3. **Customer key uniqueness:** `SELECT customer_id FROM customers GROUP BY customer_id HAVING COUNT(*) > 1` returns no rows.
-4. **Known-answer fixture:** five orders in September 2026 New York time: one with no refund, one with a single refund, one with two partial refunds, one with only a reversed refund, and one placed by a test account and refunded. Expected rate: 2 of 4 = 50.0%.
-
-## Change log
-
-| Version | Date | Change | Approved by |
-|---|---|---|---|
-| v1 | 2026-10-01 | Initial definition | pending: finance analytics lead |
-
-## Open decisions
-
-- [ ] Does a refund with NULL status count? Defaulted to yes. Confirm with the finance analytics lead.
-- [ ] Lock period of 60 days after month end. Confirm with the finance analytics lead against the refund policy window.
-- [ ] Is `customers.customer_id` unique? Check 3 answers it.
-- [ ] Support's `refund_tickets` metric needs its own spec, owned by support.

package/packs/data-analytics/skills/metric-definition/manifest.json

@@ -1,41 +0,0 @@
-{
-  "name": "metric-definition",
-  "version": "0.1.1",
-  "description": "Write a metric spec precise enough for a semantic layer or dbt metric to implement and for two analysts to get the same number — name, business question, exact numerator and denominator, grain, time window and timezone, filters and exclusions (test accounts, refunds), allowed dimensions, edge cases (NULLs, late data, currency), owner, reference SQL, and the sanity checks that catch it going wrong. Use when the user says \"define this metric\", \"how exactly do we calculate X\", \"finance and product get different numbers for X\", \"write the metric spec for our semantic layer\", or \"what counts as an active user\".",
-  "entrypoint": "SKILL.md",
-  "deps": {
-    "npm": [],
-    "pip": []
-  },
-  "env": {
-    "required": [],
-    "optional": []
-  },
-  "related": [
-    "dashboard-spec",
-    "data-contract",
-    "observability-plan",
-    "sql-review",
-    "success-metrics"
-  ],
-  "handoff": [
-    {
-      "to": "sql-review",
-      "when": "the reference SQL is written and the metric is about to be certified",
-      "purpose": "Check the reference SQL for fan-out, NULL and timezone bugs before it becomes the tie-breaker.",
-      "fallback": "If sql-review is absent, run the spec's join-integrity and known-answer checks and note that the SQL has not been independently reviewed."
-    }
-  ],
-  "tags": [
-    "metrics",
-    "semantic-layer",
-    "dbt",
-    "analytics",
-    "data-quality",
-    "definitions"
-  ],
-  "model": {
-    "tier": "standard",
-    "rationale": "Structured specification against a fixed checklist (formula, grain, window, exclusions, edge cases, checks). Needs care with SQL and additivity but no adversarial judgment."
-  }
-}

package/packs/data-analytics/skills/metric-definition/reference.md

@@ -1,67 +0,0 @@
-# metric-definition reference
-
-## Metric types and their traps
-
-| Type | Example | Additive across time and dimensions? | Trap |
-|---|---|---|---|
-| Count | orders | Yes | Counting rows of a joined table instead of the entity |
-| Sum | revenue_usd | Yes, within one currency | Mixed currencies; refunds netted in some places and not others |
-| Distinct count | active_customers | **No** | Summing daily or regional counts double-counts entities present in several |
-| Ratio | refund_rate | **No** | Averaging per-day or per-segment ratios instead of dividing the sums |
-| Average | avg_order_value | **No** | It's a ratio (sum / count): roll up the parts, not the averages |
-| Percentile | p90_delivery_hours | **No** | Percentiles can't be combined; recompute from raw rows |
-| Cumulative | customers_to_date | No (it is a running total) | Restating history when late rows land in an old period |
-
-For every non-additive metric, the spec says: *"To roll up, recompute from the base rows; never sum or average the reported values."* A semantic layer that stores the numerator and denominator separately can roll up ratios correctly; one that stores only the ratio can't.
-
-## Exclusion checklist
-
-Ask about each. Every one that applies gets a predicate and a reason in the spec.
-
-- Test, QA, demo and internal/staff accounts
-- Refunds, chargebacks, cancellations and voids (and partial refunds)
-- Fraudulent or blocked transactions
-- Deleted, merged or anonymised records (including after a privacy erasure request)
-- Zero-value, free-tier or 100%-discount transactions
-- Duplicates from retries or event replays
-- Records outside the product's scope (wholesale orders, a sister brand)
-
-## Edge-case checklist
-
-| Case | The spec must say |
-|---|---|
-| NULL in a formula column | Counted, excluded, or defaulted, and to what |
-| Zero denominator | Show NULL (blank), not 0. 0% claims something happened. |
-| Late-arriving data | How many days a closed period may change; when it locks; whether restatements are announced |
-| Currency | Source of rates, which date's rate (transaction date or period end), and the reporting currency |
-| Timezone and DST | IANA zone name; what a "day" means on 23- and 25-hour days |
-| Week definition | ISO week (Monday start) or another start day, and how week 1 is numbered |
-| Backfills | Whether historical values change when a backfill runs, and who is told |
-| Definition change | New version number, change-log entry, cutover date; old version kept queryable for comparison |
-
-## Sanity-check catalogue
-
-Pick at least three. Each is written as a runnable query or test, not a description.
-
-1. **Reconciliation with a system of record.** The metric's total for a closed period matches the ledger, billing system or source report within a stated tolerance.
-2. **Bounds.** Rates within 0 and 1; counts not negative; revenue not negative unless refunds are netted.
-3. **Additivity.** For additive metrics only, the sum over a dimension equals the total. For distinct counts, the sum over a dimension is **at least** the total.
-4. **Join integrity.** Row count of the base population before and after each dimension join is equal.
-5. **Known-answer fixture.** 5–10 hand-built rows covering each exclusion and edge case, with the expected result worked out by hand. Run it in CI (a dbt unit test or a plain SQL assertion).
-6. **Period-over-period alert.** A change beyond a stated threshold (for example ±30% week over week) opens a ticket to check before anyone reports it.
-7. **Freshness.** The latest timestamp in the source is recent enough for the window being reported.
-
-## Mapping to a semantic layer
-
-Semantic layers differ in syntax but share the same parts. Map the spec's fields like this, then write the definition in your tool's own syntax and check it against that tool's documentation.
-
-| Spec field | Semantic layer concept |
-|---|---|
-| Entity | Primary entity or key of the model |
-| Time column and window | Aggregation time dimension and granularity |
-| Numerator, denominator | Measures (an aggregation plus an expression), combined in a ratio metric |
-| Filters and exclusions | A filter on the metric or measure, or exclusion done in the underlying model |
-| Allowed dimensions | Dimensions reachable through declared joins or entity relationships |
-| Owner, status, version | Metadata or `meta` fields, plus the repo's code owners |
-
-dbt's MetricFlow, for example, defines measures inside semantic models and offers simple, ratio, cumulative, derived and conversion metric types; a ratio metric there names a numerator metric and a denominator metric. Cube, LookML and other tools use their own terms for the same parts. Do the exclusions in the modelled table where you can, so every metric built on it inherits them, rather than repeating the filter in each metric.

package/packs/data-analytics/skills/metric-definition/templates/metric-spec.md

@@ -1,70 +0,0 @@
-# Metric: `<metric_name>` (v<N>, <draft | certified>)
-
-**Business question:** <one sentence: what decision this number informs, and for whom>
-**Owner:** <role, team> · **Status:** <draft | certified> · **Last changed:** <YYYY-MM-DD>
-
-## Formula
-
-| Part | In words | As an aggregation |
-|---|---|---|
-| Numerator | <what is counted or summed> | `<COUNT(DISTINCT x) / SUM(y) ...>` |
-| Denominator | <population it is divided by, or "none"> | `<...>` |
-
-- **Type:** <count | sum | distinct count | ratio | average | percentile | cumulative>
-- **Unit and format:** <%, 1 decimal | USD, 0 decimals | count>
-
-## Grain and time
-
-- **Entity:** <order | customer | account | session>
-- **Time column:** `<table.column>`, because <why this timestamp and not another>
-- **Window:** <calendar month | ISO week | rolling 28 days | trailing 7 complete days>, half-open (`>= start AND < end`)
-- **Timezone:** `<IANA name>`
-- **Partial periods:** <shown and marked "to date" | hidden until complete>
-- **Additivity:** <additive across time and dimensions | not additive: recompute from base rows to roll up>
-
-## Filters and exclusions
-
-| Exclusion | Predicate | Reason |
-|---|---|---|
-| <test accounts> | `<SQL>` | <why> |
-
-## Dimensions
-
-| Dimension | Source column | Join path | Cardinality | Allowed? |
-|---|---|---|---|---|
-| <region> | `<customers.region>` | `<orders.customer_id = customers.customer_id>` | <many-to-one> | <yes> |
-| <product category> | `<...>` | `<...>` | <one-to-many: fans out> | <no, or allocation rule> |
-
-## Edge cases
-
-| Case | Rule |
-|---|---|
-| NULLs | <...> |
-| Zero denominator | <NULL, not 0> |
-| Late data | <closed period can change for N days; locks on day N+1> |
-| Currency | <rate source and date> |
-| Timezone and DST | <...> |
-| Duplicates | <...> |
-
-## Reference SQL (<dialect>)
-
-```sql
--- base population, exclusions, numerator, denominator: one CTE each
-```
-
-## Sanity checks
-
-1. <reconciliation with system of record: query and tolerance>
-2. <bounds>
-3. <join integrity or additivity>
-4. <known-answer fixture>
-
-## Change log
-
-| Version | Date | Change | Approved by |
-|---|---|---|---|
-| v1 | <YYYY-MM-DD> | Initial definition | <owner> |
-
-## Open decisions
-
-- [ ] <choice made by default> — confirm with <role>