@malloy-publisher/skills 0.1.17 → 0.1.19

package/package.json

@@ -1,7 +1,7 @@
 {
    "name": "@malloy-publisher/skills",
    "description": "Agent skills for Malloy and the Malloy Publisher",
-   "version": "0.1.17",
+   "version": "0.1.19",
    "license": "MIT",
    "type": "module",
    "main": "dist/index.js",
@@ -41,7 +41,7 @@
       "typecheck": "bunx tsc --noEmit",
       "lint": "bunx eslint ./src ./scripts --fix",
       "format": "bunx prettier --write --parser typescript '{src,scripts}/**/*.ts'",
-      "test": "bun run copy-skills && bun test src"
+      "test": "bun run copy-skills && bun test ./src"
    },
    "devDependencies": {
       "@eslint/js": "^8.57.0",

package/skills/eval-answer/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: eval-answer
 description: 'Score one analytical answer against a verified golden, and score which of the entities the golden depends on retrieval delivered to the answerer. Run the contamination checklist, re-execute the submitted query yourself, then spawn a judge subagent per skill:eval-judge. Append attempt, tool_call, score, and retrieval_score events to the file ledger (reference/ledger-schema.md). Never explain the failure (eval-diagnose) or edit the model (eval-improve). Use when asked whether an answer was correct, to score a run, or to baseline a model.'
-version: 0.1.17
+version: 0.1.19
 ---
 
 # Evaluate One Answer

package/skills/eval-diagnose/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: eval-diagnose
 description: 'Diagnose why a scored answer failed and who owns the fix, then cluster the failures by shared root cause. Walk dataset, agent-call, get_context/model, get_context/retrieval, construction, then model-definition. Append issue events to the file ledger, linked by traceId, one per cluster. Use after eval-answer, when triaging a run, or before changing a model. Does not edit the model (eval-improve).'
-version: 0.1.17
+version: 0.1.19
 ---
 
 # Diagnose One Answer

package/skills/eval-import/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: eval-import
 description: 'Turn a list of questions into an eval set, whatever shape it arrived in: a JSONL a customer sent, a CSV, a spreadsheet export, a markdown doc, an email thread, or a pull from production logs. Classify each item by what came WITH the question (a query, a number, prose criteria, or nothing), write cases.jsonl and set.json per reference/case-format.md, keep the file as it arrived, and seal each question so a later edit is detectable. Never marks a value-bearing golden verified and never invents a question. Use when questions arrive from outside and need to become a set, or before the first run against a set nobody here authored.'
-version: 0.1.17
+version: 0.1.19
 ---
 
 # Import questions into an eval set

package/skills/eval-improve/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: eval-improve
 description: 'Make the smallest safe Malloy model edit that closes a diagnosed model-owned gap, with a probe receipt for every factual claim. Use after eval-diagnose, or when asked to fix a model so an agent can discover the right answer. Never accepts its own edit; the acceptance check belongs to eval-loop. Does not decide whether an answer was wrong (eval-answer) or why (eval-diagnose).'
-version: 0.1.17
+version: 0.1.19
 ---
 
 # Improve the Model

package/skills/eval-judge/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: eval-judge
 description: 'Decide whether ONE answer matches its golden, and say whether you believe the golden. Read this before emitting any verdict. Covers containment, column pairing, near_match, refusals, and the gold_status judgement. Use when scoring an attempt in an evaluation run; never to conduct a run (eval-loop), diagnose a failure (eval-diagnose) or edit a model (eval-improve).'
-version: 0.1.17
+version: 0.1.19
 ---
 
 # The judge

package/skills/eval-loop/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: eval-loop
 description: 'Conduct a local Publisher evaluation loop in five steps: scrape/run, eval, diagnose, improve, checkpoint. You are the conductor: import cases into the file ledger, spawn a blind answerer, then run eval-answer, eval-diagnose, and eval-improve. Persistence is plain files under the model package''s evals/ directory; checkpoints are git commits of the model repo. Use to score a model, diagnose failures, improve behind an acceptance check, or roll back a bad direction.'
-version: 0.1.17
+version: 0.1.19
 ---
 
 # The Evaluation Loop

package/skills/malloy/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy
 description: Index of all Malloy skills. Use when user asks "malloy help", "what malloy skills are available", "how do I use malloy", or needs guidance on which Malloy skill to use.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-analysis/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-analysis
 description: Workflow for answering data questions against Malloy semantic models over MCP - structured discovery with get_context, query construction with execute_query, verification, and answer delivery. Use whenever the user asks a data question, wants a metric, a breakdown, a trend, or a chart over a model.
-version: 0.1.17
+version: 0.1.19
 ---
 
 <!--

package/skills/malloy-analysis-pitfalls/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-analysis-pitfalls
 description: Common data analysis pitfalls to watch for during query construction and result interpretation. Reference this checklist when verifying queries and results to catch errors before presenting an answer.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-analysis-report/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-analysis-report
 description: Combine validated Malloy queries into a notebook report or dashboard. Use when the user asks to "create a report", "build a dashboard", "combine these into a report", or wants a persistent multi-query artifact.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-analyze/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-analyze
 description: Open-ended exploration with no specific question to answer, and building views/dashboards/notebooks on an existing model. Use when the user asks "what's interesting?", "explore this data", "find insights", "look for patterns", "build a dashboard", or "create views". Not for a specific data question - answering one is `malloy-analysis`, and writing down what the answer assumed is `malloy-model-as-you-go`. For exploration start at Step 1; for views on an existing model jump to View Patterns.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-charts/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-charts
 description: Chart selection guidance and renderer reference for Malloy views. Use when choosing visualization types, adding chart annotations, user asks "what chart should I use", "how should I visualize this", or when deciding between bar_chart, line_chart, scatter_chart, etc.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-dashboards/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-dashboards
 description: "Build or modify a Malloy Publisher dashboard, a tagged .malloy file in a package's dashboards/ directory, with auto-rendered filter controls, a grid layout, and # drill click-through. Use when the user asks for a dashboard, a filterable operational view, or drill-through between views, and no code is wanted."
-version: 0.1.17
+version: 0.1.19
 ---
 
 <!--
@@ -35,14 +35,18 @@ Scanned at a glance is a dashboard; read top to bottom is a notebook.
 2. **PICK THE VIEWS TO SHOW.** A dashboard is `## artifact { tiles=[…] }` naming existing views, so
    this is the design step: which views, how wide each sits, what each is called. There is one form,
    so there is no form to choose.
-3. **DECLARE THE GIVENS** the dashboard will filter by, in the model (usually `givens.malloy`), with
-   their control tags: see "Filter controls" below for the syntax and what each tag renders as. Skip
-   if they already exist, since a given is a model concern and dashboards share them.
+3. **DECLARE THE GIVENS** the dashboard will filter by, in the dashboard file itself, with their
+   control tags: see "Filter controls" below for the syntax and what each tag renders as. That is
+   the convention because the dashboard builder edits the dashboard file and nothing else, so a
+   filter it can add, change or remove is a declaration in that file. Bind them on the tiles (step
+   4). Reuse the package's `givens.malloy` only for a control several surfaces genuinely share, and
+   then import it whole, knowing the builder can bind those givens but not edit them.
 4. **COMPOSE THE FILE** for `dashboards/`, following the template below, but do not save it yet.
-   Import the package's givens file **whole**: `import '../givens.malloy'`, not a named list.
-   Only the givens the tiles reference become controls, so a whole-file import brings nothing
-   extra, and a named list is one more thing to forget; forgetting one costs you a missing control
-   rather than an error. Sources are the other way round: name the few you need. Then import every
+   Name the sources you need: `import { order_items, products } from '../storefront.malloy'`.
+   Each tile binds its controls with a refinement, `view: t is v + { where: category ~ $CATEGORY }`,
+   one clause per given it answers to; a `filter<...>` binds with `~`, a plain `date` or `number`
+   given is a value and binds with `>=`, `<=` or `=`. Only the givens some tile references become
+   controls, so a declaration nothing binds shows nothing. Then import every
    source or query any referenced given names in a `suggest`. Both are per-file, and getting the
    suggest wrong does not error: the control still looks like a picker but has no options, and says
    so underneath, "Could not load the options for this control". The package warnings name it too. **A `suggest` naming a `query=` needs that
@@ -77,33 +81,31 @@ out by Publisher into the grid `# dashboard { columns=N }` names.
 ```malloy
 ##! experimental.givens
 ## artifact { title="Storefront overview" tiles=["overview -> kpis", "overview -> revenue_trend", "overview -> revenue_by_state"] } dashboard { columns=12 }
-import { scoped_sales } from './_shared.malloy'
-import { products } from '../storefront.malloy'
-import '../givens.malloy'
+import { order_items, products } from '../storefront.malloy'
+
+// The controls, declared here: the tags are each one's control contract.
+# label="Category" control=select suggest { source=products dimension=category }
+given: CATEGORY :: filter<string> is f''
+# label="Ordered since"
+given: SINCE :: date is @2023-01-01
 
 // Layout goes on the VIEW, and a thin re-declaration is the place to put it: the
-// modelled view keeps its chart tag, and this decides how wide it sits here.
-source: overview is scoped_sales extend {
+// modelled view keeps its chart tag, this decides how wide it sits here, and the
+// `+ { where: ... }` says which controls the tile answers to.
+source: overview is order_items extend {
   # colspan=12
   # label="Key figures"
   # big_value
-  view: kpis is {
-    aggregate:
-      # label="Revenue"
-      # currency
-      total_sales
-      # label="Orders"
-      order_count
-  }
+  view: kpis is key_figures + { where: category ~ $CATEGORY, where: created_at >= $SINCE }
 
   # colspan=8
   # break
   # label="Revenue by month"
-  view: revenue_trend is sales_by_month
+  view: revenue_trend is sales_by_month + { where: category ~ $CATEGORY, where: created_at >= $SINCE }
 
   # colspan=4
   # label="Revenue by state"
-  view: revenue_by_state is sales_by_state
+  view: revenue_by_state is sales_by_state + { where: category ~ $CATEGORY, where: created_at >= $SINCE }
 }
 ```
 
@@ -116,8 +118,8 @@ Three things the form costs, so you are not surprised by them:
 - **A tile expression is a string in an annotation, so the compiler never checks it.** Rename a view
   and the file still compiles; the tile fails at package load. Read the lint (step 6).
 - **No per-parent-row grouping.** There is no parent query to repeat a grid over.
-- **Filtering lives in what the tiles name**, not on the page. That is the shared include's job,
-  below.
+- **Filtering lives on the tiles**, not on the page: each view's `+ { where: ... }` names the
+  controls it answers to. Below is why, and the one thing that does not work.
 
 ### Also served: `# artifact` on a `query:`
 
@@ -177,23 +179,24 @@ object", so a dashboard has no description as a result.
 
 ### Where the filtering goes
 
-A dashboard has no query, so the filtering it applies must live in what it composes: a source that
-already has the givens applied. Put it in an untagged `dashboards/_shared.malloy`, which discovery
-treats as a shared include rather than a dashboard. **It has to apply every given the dashboard
-imports**: a given the dashboard imports but nothing references gets no control, silently, at reload
-200 with no warning. Note `SINCE` is a `date` rather than a `filter<>`, so it compares with `>=`
-rather than `~`. Save the include before you compile the dashboard that imports it, since an importer
-compiled against a sibling that is not on disk fails with an `import-error`.
-
-```malloy
-##! experimental.givens
-import { order_items } from '../storefront.malloy'
-import '../givens.malloy'
-
-source: scoped_sales is order_items extend {
-  where: products.category ~ $CATEGORY and created_at >= $SINCE
-}
-```
+A dashboard has no query, so its filtering lives on the views it names: a `+ { where: field ~ $GIVEN }`
+refinement on each tile, one clause per control the tile answers to. A tile without the clause does
+not move when the control does, which is how a page keeps one tile fixed while the rest filter. The
+givens those clauses read are declared in the same file (step 3).
+
+**Binding is per declaration, not per name.** Measured: a dashboard declaring its own `CATEGORY`
+over a source whose model-level `where:` reads the model's `CATEGORY` compiles, shows the control,
+and filters nothing when it moves, because the two declarations only share a name. So do not mix
+the two designs on one given. The other design still works on its own: a source with the givens
+already applied in an untagged `dashboards/_shared.malloy`, reading `import '../givens.malloy'`,
+which discovery treats as a shared include rather than a dashboard. Then the dashboard imports both
+and the controls render for the givens its tiles reach. A given the dashboard imports but nothing
+references gets no control, silently, at reload 200 with no warning. Save the include before you
+compile the dashboard that imports it, since an importer compiled against a sibling that is not on
+disk fails with an `import-error`. The builder can bind such a control but not add, change or
+remove it, since it never edits imports or model files.
+
+Note `SINCE` is a `date` rather than a `filter<>`, so it compares with `>=` rather than `~`.
 
 **`# dashboard { columns=N }` is the one spelling of the grid width**, on both forms, beside the
 artifact tag. Anything else inside the artifact tag is a package warning naming it, which is what you
@@ -275,9 +278,10 @@ rows.
 - **The filename is the dashboard's name:** its URL slug, its listing name, and its `# drill`
   target. The query inside can be called anything, and sometimes must be (a query named `regions`
   collides with an imported `regions` source).
-- **Importing a given is what makes it bindable.** Malloy's given namespace is per-file. A given the
-  dashboard file does not import gets no control and cannot be sent to it, even when the `where:`
-  that references it lives up an import chain. A dashboard must import the givens its tiles use.
+- **A given has to be in the dashboard file's scope to be bindable**: declared there (the
+  convention) or imported. Malloy's given namespace is per-file. A given the file cannot see gets
+  no control and cannot be sent to it, even when a `where:` that references it lives up an import
+  chain. And a given declared here does not drive a `where:` in the model: bind on the tiles.
 - **A suggest's source or query has to resolve in the dashboard file too.** `suggest { source=products … }`
   means the dashboard imports `products`.
 - **A model-level `##` tag must be on one line.** Wrapping one always breaks it, but how you find
@@ -296,9 +300,10 @@ choosing them.
 
 ## Filter controls
 
-Controls come from the `given:` declarations the query references, and the tags on the declaration
-are the control contract, declared once and identical on every dashboard and in every notebook that
-uses them:
+Controls come from the `given:` declarations the tiles reference. Declare them in the dashboard
+file, which is what the builder edits; a package `givens.malloy` is for controls the data app and
+notebooks share, and a dashboard importing it whole gets the same controls but cannot edit them.
+The tags on the declaration are the control contract:
 
 ```malloy
 ##! experimental.givens

package/skills/malloy-debug/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-debug
 description: Fix Malloy compile errors and understand error messages. Use when encountering errors in .malloy files, user says "fix this error", "malloy error", "compile error", "syntax error", or sees 20+ cascading errors.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-define/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-define
 description: Propose a source plan and field definitions for a Malloy semantic model. Covers picking which sources to model and at what grain, then proposing the specific renames, dimensions, and measures per source, every proposal backed by querying the data.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-discover/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-discover
 description: Silent data discovery for Malloy modeling. Used at Step 1 of the modeling workflow. Scans tables, columns, distributions, and relationships without user interaction. The agent builds an internal picture before presenting anything.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-document/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-document
 description: 'Add documentation with #(doc) tags to Malloy models so fields and sources are described in plain language. Use when user asks to "add documentation", "add doc tags", "document the model", or wants fields and sources described for natural-language search and discovery. For declaring parameterizable filters with #(filter), see the malloy-model skill. Filters are a runtime/modeling construct (governance, latency, correctness), not a documentation tag.'
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-getting-started/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-getting-started
 description: First steps for using a Malloy Publisher deployment through its MCP tools. Use when connecting to Publisher for the first time, when you do not yet know the available environments, packages, or models, or when a user asks what data they can explore. Covers verifying the server, discovering data with get_context, and running a first grounded query.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-gotchas-modeling/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-gotchas-modeling
 description: Common Malloy modeling mistakes and how to avoid them. Read BEFORE writing source definitions, dimensions, measures, or joins. Covers reserved words, NULL checks, date functions, type casts, field management (extend except/accept/rename vs include public/internal/private), and query-based source gotchas.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-gotchas-queries/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-gotchas-queries
 description: Common Malloy query and view mistakes. Read BEFORE writing views, queries, or notebooks. Covers chart constraints, aggregate filters, joined field aliasing, method syntax, and time truncation vs extraction.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-gotchas-rendering/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-gotchas-rendering
 description: Common Malloy renderer annotation mistakes. Read BEFORE adding chart annotations, formatting tags, or building dashboards. Covers tag syntax, scale rules, sparkline setup, and big_value patterns.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-html-data-app-embedding/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-html-data-app-embedding
 description: Embed an in-package HTML data app into a host page or another application, including auto-sizing and auth. Read when embedding a Publisher page via Publisher.embed.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-html-data-app-runtime/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-html-data-app-runtime
 description: Write the JavaScript that drives an in-package HTML data app, calling Publisher.query, building queries from filter state, and handling results and errors. Read before writing the page's data code.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-html-data-apps/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-html-data-apps
 description: Build or modify an in-package HTML data app for a Malloy Publisher package (a public/ directory the package serves). Use when the user wants a hand-authored HTML dashboard or web page backed by a package's Malloy models, with no build step.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-lookml-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-lookml-review
 description: Analyze LookML files as prior art for Malloy modeling. Used during Step 1 (DISCOVER) when .lkml files are present. Coordinates reference files that extract business logic, relationships, and curation decisions. Works with or without a database connection.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-materialization/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-materialization
 description: Add and debug Malloy Persistence materializations in a package - persist an expensive source so queries read a pre-built table. Read this whenever the user wants to materialize a source, add a persist annotation, speed up a slow source, or asks why a persist source isn't building.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-materialization-tuning/SKILL.md

@@ -1,8 +1,9 @@
 ---
 name: malloy-materialization-tuning
 description: Optimize a package's Malloy Persistence materializations for cost and performance using the malloy-pub CLI and the materialization history. Recommend what to persist, what to stop persisting, and how to schedule/scope it. Use when the user asks to make a package cheaper or faster, tune persistence, decide what to materialize, or review persist/schedule choices.
-version: 0.1.17
+version: 0.1.19
 ---
+
 <!--
 Copyright (c) Credible Data Inc.
 SPDX-License-Identifier: MIT
@@ -33,20 +34,14 @@ Establish what the package persists today and how it is governed.
 
 The history is where cost lives. Each run records its trigger, timing, and how many sources were built vs reused.
 
-- **Across the whole environment** (all packages, newest first; the rows are interleaved and labeled by package, not grouped into contiguous per-package blocks):
-
-  ```bash
-  malloy-pub list materialization --environment <env>
-  ```
-
-  Columns: Package, ID, Status, **Trigger** (`SCHEDULER` vs `ON_DEMAND`), Started, Completed, Error.
-
-- **For one package:**
+- **For one package** (newest first). A materialization is a run of one package's persist sources, so this is the listing; to review a whole environment, read each package in turn (`malloy-pub list package --environment <env>` names them):
 
   ```bash
   malloy-pub list materialization --environment <env> --package <pkg>
   ```
 
+  Columns: ID, Status, **Trigger** (`SCHEDULER` vs `ON_DEMAND`), Started, Completed, Error.
+
 - **A single run's detail** (the cost signals):
 
   ```bash

package/skills/malloy-model/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-model
 description: Build Malloy semantic models with base source and joined source files. Use when creating or modifying .malloy files, user asks to "create a malloy model", "add dimensions", "add measures", "create a source", or any Malloy model authoring task.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-model-as-you-go/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-model-as-you-go
 description: After answering a data question, write down what the answer assumed so the next reader can trust the number. A field with a #(doc) in the model when you can edit it, an extend in the notebook when you can only author reports, or a stated assumption plus a Malloy snippet when you can only chat. Use after every answered question that rested on a judgment call, and whenever a question is asked against tables that have no model yet.
-version: 0.1.17
+version: 0.1.19
 ---
 
 <!--

package/skills/malloy-modeling/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-modeling
 description: Build semantic models with Malloy for the Malloy Publisher. Read this skill whenever the user asks about modeling data or specifically mentions Malloy.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-notebook-chat/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-notebook-chat
 description: Steps to follow when the chat is bound to a notebook or saved report. The notebook's cells are the agent's primary context, answer from it, run its queries, and only reach for get_context when the user asks about something outside it.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-notebooks/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-notebooks
 description: Create Malloy notebooks (.malloynb) for interactive dashboards and data stories. Use when user asks to "create a notebook", "make a dashboard notebook", "write a malloynb", "data story", or needs to build reports/visualizations.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-patterns/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-patterns
 description: Index of Malloy documentation topics. Use to discover what's available in search_malloy_docs. Covers language reference (sources, queries, views, fields, aggregates, joins, filters, expressions, functions), common patterns (YoY, cohorts, percent of total), rendering, and experimental features.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-phrase-detection/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-phrase-detection
 description: How to construct search targets for the get_context tool. Covers target-type classification and non-obvious decomposition patterns. Read the tool description for field definitions and the end-to-end workflow.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-publish/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-publish
 description: Package Malloy models for serving by Malloy Publisher. Use when user asks to "publish", "package", "deploy", or wants to share models with others.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-queries/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-queries
 description: Malloy query patterns, syntax rules, and chart annotation reference. Consult before writing or debugging any query. Covers dates, aggregates vs dimensions, join paths, filters, string matching, and common error patterns.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-review
 description: Malloy semantic-model code review. Invoke when the user asks to review, audit, or critique a `.malloy` file, a folder of Malloy models, or a GitHub PR that touches Malloy. Enforces project modeling standards and emits a navigable review file.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.

package/skills/malloy-scope/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-scope
 description: Present discovery findings and propose an analytical scope before modeling. Use after inspecting a package's model and data, to classify tables and recommend an analytical focus the user can pick from.
-version: 0.1.17
+version: 0.1.19
 ---
 <!--
 Copyright (c) Credible Data Inc.