@malloy-publisher/skills 0.1.9 → 0.1.10

package/package.json

@@ -1,7 +1,7 @@
 {
    "name": "@malloy-publisher/skills",
    "description": "Agent skills for Malloy and the Malloy Publisher",
-   "version": "0.1.9",
+   "version": "0.1.10",
    "license": "MIT",
    "type": "module",
    "main": "dist/index.js",

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.9
+version: 0.1.10
 ---
 <!--
 Copyright (c) Credible Data Inc.
@@ -42,7 +42,8 @@ Every skill in this deployment, by what it is for. Start at a driver; it routes
 
 | Skill | Use when... |
 |-------|-------------|
-| `skill:malloy-analyze` | Exploratory data analysis: profiling, building views and dashboards |
+| `skill:malloy-model-as-you-go` | After answering a question, writing down what it assumed: a `#(doc)`'d field in the model, an `extend` in the notebook, or a stated assumption plus snippet, depending on what the session can write |
+| `skill:malloy-analyze` | Open-ended exploration with no intent to keep anything: profiling, hypotheses, views |
 | `skill:malloy-charts` | Chart selection and renderer reference for Malloy visualizations |
 | `skill:malloy-notebooks` | Building Malloy notebooks (.malloynb) |
 | `skill:malloy-analysis-report` | Combining validated queries into a notebook report or dashboard |

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.9
+version: 0.1.10
 ---
 <!--
 Copyright (c) Credible Data Inc.

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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 Copyright (c) Credible Data Inc.
@@ -24,7 +24,7 @@ Do NOT build the notebook in the same turn as `execute_query`. Explain first, th
 
 ## Filters are inherited from the model, don't declare them in the report
 
-Reports do not (and cannot) define their own filters. If the source has `#(filter)` annotations, Publisher renders the filter widgets, parses caller parameters, and injects `where:` clauses server-side automatically: the report inherits and displays those filters with no extra work. If the analysis needs a knob the source doesn't expose, the right move is to add a `#(filter)` to the source itself (see your modeling workflow's parameterizable-filter guidance for `#(filter)`), not to wedge a filter widget into the report. For curated notebooks with their own per-notebook filter UI on top of the model, see `skill:malloy-notebooks` instead.
+Reports do not (and cannot) define their own filters. If the source declares `given:` parameters (or legacy `#(filter)` annotations), Publisher renders the controls, parses caller parameters, and applies them server-side automatically: the report inherits and displays them with no extra work. If the analysis needs a knob the source doesn't expose, the right move is to add a `given:` to the source itself, not to wedge a filter widget into the report. `#(filter)` is deprecated in favour of native Malloy `given:` parameters. Do not add new `#(filter)` annotations; the two exceptions are `required` and `implicit`, which `given:` cannot cover yet. See `skill:malloy-model` § Legacy: Parameterizable Filters. For curated notebooks with their own per-notebook filter UI on top of the model, see `skill:malloy-notebooks` instead.
 
 ## What goes in the report
 

package/skills/malloy-analyze/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: malloy-analyze
-description: Explore data for insights and build views/dashboards/notebooks. Use when user asks to "analyze this data", "find insights", "explore for patterns", "what's interesting", "what's driving X", "build a dashboard", "create views", or any analysis task. For EDA exploration, start at Step 1. For building views on an existing model, jump to View Patterns.
-version: 0.1.9
+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.10
 ---
 <!--
 Copyright (c) Credible Data Inc.
@@ -254,7 +254,9 @@ A notebook is also the home for a polished, narrated report: alternate `>>>markd
 
 ### Interactive Filters
 
-**Notebooks do NOT define filters themselves.** When you import a model, the model's `#(filter)` annotations on the source are **inherited and displayed automatically**: the publisher renders the filter widgets, parses caller parameters, and injects `where:` clauses server-side. You don't redeclare them in the consumer. If the analysis needs a knob the model doesn't expose, the right move is to add a `#(filter)` to the source itself (see `skill:malloy-model` § Parameterizable Filters with `#(filter)`), not to wedge filtering into the consumer.
+**Notebooks do NOT define filters themselves.** When you import a model, the model's runtime parameters are **inherited and displayed automatically**: the publisher renders the controls, parses caller parameters, and applies them server-side. You don't redeclare them in the consumer. If the analysis needs a knob the model doesn't expose, the right move is to add it to the source itself, not to wedge filtering into the consumer.
+
+**Declare that knob as a `given:`.** `#(filter)` is deprecated in favour of native Malloy `given:` parameters. Do not add new `#(filter)` annotations; the two exceptions are `required` and `implicit`, which `given:` cannot cover yet. See `skill:malloy-model` § Legacy: Parameterizable Filters.
 
 The notebook-level `##(filters)` annotation and the dimension-level `#(filter) {"type": "..."}` JSON-blob form are **unsupported legacy syntax**, don't use them. The only supported form is `#(filter) name=... dimension=... type=...` declared above the source.
 

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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 Copyright (c) Credible Data Inc.
@@ -31,8 +31,9 @@ Scanned at a glance is a dashboard; read top to bottom is a notebook.
    `malloy_getContext` if you have it, otherwise the REST model endpoint or the `.malloy` files.
    Never guess a name. A guessed field in a query fails the whole package load, not just that one
    dashboard; a guessed tile or suggest source is quieter, and only shows up in the package warnings.
-2. **DECIDE THE FORM** (below): single-query if the page is one filtered result with parts;
-   composite if the views already exist and the job is choosing which to show together.
+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.
@@ -40,7 +41,11 @@ Scanned at a glance is a dashboard; read top to bottom is a notebook.
    Import every given it filters by, and every source or query any of those givens 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.
+   this control". The package warnings name it too. **A `suggest` naming a `query=` needs that
+   query's own source imported as well**, because an import is not transitive: the query resolves by
+   name, so the file compiles and the package loads, but running the picker fails with
+   `Undefined source '<name>'`. The package warnings name this one too, saying which source to
+   import. Import the source that suggest query reads, not just the query.
 5. **COMPILE IT** with `malloy_compile` (or `POST …/models/<path>/compile`), against the source text,
    before you save, at the path the file will have. **Editing one that already exists needs
    `"scope": "file"`**, which compiles your source AS that file; the default appends it instead, so
@@ -48,7 +53,7 @@ Scanned at a glance is a dashboard; read top to bottom is a notebook.
    already-defined errors that reads as broken Malloy rather than a wrong scope. **Editing a shared
    include wants `"scope": "package"`**, which recompiles every file as saved: `file` only checks the
    one you are editing, so renaming a source in `_shared.malloy` passes it while breaking every
-   composite that imports it. A clean compile is not a working dashboard: some tag mistakes surface
+   dashboard that imports it. A clean compile is not a working dashboard: some tag mistakes surface
    at step 6, and some only when you look at the page in step 7. (The third scope, `append`, is the
    default and is what a not-yet-saved file gets.)
 6. **SAVE IT, RELOAD, AND READ THE MANIFEST AND THE WARNINGS.** `malloy_reloadPackage`, or
@@ -60,9 +65,63 @@ Scanned at a glance is a dashboard; read top to bottom is a notebook.
    and its `query` is the name to run in step 7. See "Read the lint" below.
 7. **OPEN IT AND LOOK.** Not optional; see "What 'done' means".
 
-## The two forms
+## The form
 
-**Single-query:** one query whose result is the dashboard. Reach for this by default.
+A dashboard is `## artifact { tiles=[…] }` at model level: named views, each run as its own query, laid
+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 { CATEGORY, SINCE } from '../givens.malloy'
+
+// 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 {
+  # colspan=12
+  # label="Key figures"
+  # big_value
+  view: kpis is {
+    aggregate:
+      # label="Revenue"
+      # currency
+      total_sales
+      # label="Orders"
+      order_count
+  }
+
+  # colspan=8
+  # break
+  # label="Revenue by month"
+  view: revenue_trend is sales_by_month
+
+  # colspan=4
+  # label="Revenue by state"
+  view: revenue_by_state is sales_by_state
+}
+```
+
+Model-level because there is no query of its own to hang a `#` tag on, and model-level for a second
+reason: tiles run as separate queries, which is the only way a page can span unrelated sources. A
+nest's pipeline starts from its own query's source and there is no way to combine two.
+
+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.
+
+### Also served: `# artifact` on a `query:`
+
+One query whose result is the whole page, laid out by `@malloydata/render` from the query's own
+`# dashboard` tag. This is Malloy's rendering feature, the same thing a notebook cell shows, not a
+second way to build a dashboard, and it cannot span sources. Publisher serves it, so you will meet it
+in existing packages, and the layout tags below are shared with it. Do not author a new dashboard
+this way.
 
 ```malloy
 ##! experimental.givens
@@ -108,25 +167,16 @@ query: overview is order_items -> {
 
 The `#"` line above the tag is a doc comment, and it is the page's description. If you leave `title=`
 off the artifact tag, it becomes the title instead, so write it as one, not as a sentence about the
-page. **It belongs to the query, so it only works on this form.** Putting a `#"` above a
+page. **It belongs to a query, so it only works on the one-query form.** Putting a `#"` above a
 model-level `##` tag fails the whole package load with "Object annotation not connected to any
-object", and a composite has no description as a result.
+object", so a dashboard has no description as a result.
 
-**Composite:** a list of views that already exist, each run separately into one grid. The tag is
-model-level (`##`) because there is no query of its own to hang a `#` tag on.
-
-```malloy
-##! experimental.givens
-## artifact { title="Seasonality" tiles=["scoped_sales -> sales_by_month", "scoped_sales -> sales_by_year", "scoped_sales -> seasonality"] dashboard_columns=3 }
-import { scoped_sales } from './_shared.malloy'
-import { products } from '../storefront.malloy'
-import { CATEGORY, SINCE } from '../givens.malloy'
-```
+### Where the filtering goes
 
-A composite has no query, so the filtering it applies must live in what it composes: a source that
+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 composite
-imports**: a given the composite imports but nothing references gets no control, silently, at reload
+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`.
@@ -141,42 +191,56 @@ source: scoped_sales is order_items extend {
 }
 ```
 
-Its tiles are equal-width (there is no per-tile colspan), and each one takes a single column, so
-**`dashboard_columns` is how many tiles you want per row**, not a number of twelfths. Three tiles want
-`dashboard_columns=3`. Setting it to 12 out of habit gives you twelve columns and three tiles a
-twelfth of the page wide. Use the single-query form when one tile deserves more room than the others.
+**`# 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
+will see if you write `dashboard_columns=N`: nothing reads it, and the grid would otherwise fall back
+to the default width in silence.
 
-**Write `dashboard_columns=N` on a composite and `# dashboard { columns=N }` on a single query.**
-A composite forgives the mix, since both spellings feed the manifest field it
-lays out from, but **a single query tagged `dashboard_columns` silently loses its whole layout**, and
-the manifest reports the count either way: see "Losing the grid". A composite's tiles also keep their
-own field names on their axes and column headers, and the Layout section's remedy, inlining the view,
-is not open to you here: naming existing views is the whole point of the form. `tiles=` on a
-single-query artifact tag is dropped the same way, silently.
+A tile keeps its view's own field names on axes and column headers. `# label` titles the tile; to label
+what is inside it, label the fields in the view.
 
 ## Layout: the four tags that make a page line up
 
-This section is the **single-query** form only. A composite has no colspans and counts tiles per row,
-above. Cards and tiles share one grid, so copy this recipe, and use the same count on every
-single-query dashboard in the package so they read as one product:
+Cards and tiles share one grid, and the same four tags work on both forms: on a `# dashboard` query
+the renderer reads them off each nest, and on a dashboard's `tiles=[…]` Publisher reads them off the
+view each tile names. Copy this recipe and use the same count on every dashboard in the package so
+they read as one product:
 
 1. **`columns=12`** on the `# dashboard` tag. Twelve divides by 2, 3, 4 and 6, so a row is even with
    three cards or four.
 2. **A `# colspan` on every card and tile, summing to 12 per row.** Four cards at 3, three at 4, two
    tiles at 6, a full-width table at 12. Omit them and every item falls to a single column, a twelfth
-   of the width, which is too narrow for a line chart to draw in at all.
+   of the width, which is too narrow for a line chart to draw in at all. A colspan wider than
+   `columns` is clamped, and the package warnings say so.
 3. **`# break` on the first tile after the cards.** Otherwise it flows into the columns left beside
    the cards and the next tile wraps. Not needed per row: once a row sums to 12 the next item wraps
    on its own.
-4. **`# label="…"` on every nest and every aggregate**, including the aggregates inside a table
-   nest, whose column headers are field names too. The heading is otherwise the view's or field's
-   name, and a wide table full of `total_sales` and `order_item_count` is the most visible thing
-   between a rough page and a finished one. A view nested **by name** is the exception: you can label
-   the tile, but its own field names still reach the chart axes and the column headers, so inline it
-   if you want those labelled too.
+4. **`# label="..."` on every nest, tile view, and aggregate**, including the aggregates inside a table
+   nest, whose column headers are field names too. The heading is otherwise derived from the view's or
+   field's name, and a wide table full of `total_sales` and `order_item_count` is the most visible
+   thing between a rough page and a finished one. A view referenced **by name** is the exception: you
+   can label the tile, but its own field names still reach the chart axes and the column headers, so
+   label the fields in the view if you want those too.
+
+On a dashboard, all four go on the view a tile names, which is why a thin re-declaration
+(`view: revenue_trend is sales_by_month`) is the place to put them: the modelled view stays reusable
+and each page decides its own widths. `# subtitle="..."` and `# borderless` go there too and are the
+rest of the set; a tile reads all five exactly as a `# dashboard` nest child does.
+
+**Do not forget `columns=` itself.** What you get without it differs by form, and neither is the page
+you drew. On a dashboard it falls back to a narrow default and every colspan is clamped to it, which
+is the usual reason a page you laid out comes out one item per row, and the package warnings name it.
+On a `# dashboard` query there is no grid at all: the cards flow side by side at their natural widths
+and every colspan is ignored. No package warning says so, because the renderer reports it at query
+time. See "Losing the grid".
 
 Then the traps:
 
+- **A KPI row is authored differently on the two forms.** On a `# dashboard` query a top-level
+  `aggregate:` measure IS the card, and nesting a `# big_value` view to get one renders it embedded,
+  as full-width bars in a single tile. A dashboard has no top-level aggregates, since a tile is one
+  whole result, so there a `# big_value` view IS the KPI row and renders as one. This is the only
+  place the two forms need different Malloy for the same picture.
 - **No `# size=fill` on a dashboard tile.** Inside a dashboard it measures against the container the
   whole grid was handed, not the tile, so it yields a chart thousands of pixels tall. Tiles already
   size to their colspan.
@@ -196,9 +260,9 @@ The last two are upstream renderer behavior, cheap to work around in the model.
 
 The same tags govern a `# dashboard` **view** run in a notebook cell, since both surfaces render
 through the same code, so a view laid out this way looks the same in a cell as on a dashboard page.
-Height is the one thing the surface decides: a single-query dashboard renders at its natural height,
-a composite's tiles are each capped, and in a notebook a chart cell is capped and a table cell hugs
-its rows.
+Height is the one thing the surface decides: a one-query page renders at its natural height, a
+dashboard's tiles are each capped, and in a notebook a chart cell is capped and a table cell hugs its
+rows.
 
 ## The rules that actually bite
 
@@ -207,7 +271,7 @@ its rows.
   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 composite must import the givens its tiles use.
+  that references it lives up an import chain. A dashboard must import the givens its tiles use.
 - **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
@@ -318,15 +382,14 @@ either, for a different reason.
 
 ## Losing the grid
 
-A single-query dashboard can come out with its layout wrong in two visibly different ways, and the
-reload is 200 and the manifest reports the column count you asked for in both.
+A one-query page can come out with its layout wrong in two visibly different ways, and the reload is
+200 and the manifest reports the column count you asked for in both.
 
-**Not a dashboard at all: one plain nested table**, every `# colspan` and `# break` dropped. Either
-you tagged a single query with `dashboard_columns=N`, which only a composite reads, or a `f'…'`
-filter literal in a `givens { … }`
-block shares a line with `# dashboard`. For the second, put `# dashboard` on its own line: writing it
-first on the line does not help, a plain `'Outerwear'` or a bare date is fine, and the composite form
-is immune because its layout comes from the manifest rather than a re-parse.
+**Not a dashboard at all: one plain nested table**, every `# colspan` and `# break` dropped, because a
+`f'…'` filter literal in a `givens { … }` block shares a line with `# dashboard`. Put `# dashboard` on
+its own line: writing it first on the line does not help, a plain `'Outerwear'` or a bare date is
+fine, and a `tiles=[…]` dashboard is immune because its layout comes from the manifest rather than a
+re-parse.
 
 **A dashboard, but nothing lines up**: you wrote `# colspan` without `columns=N`, so the items flow
 side by side at their natural widths instead of aligning to a grid.
@@ -355,7 +418,9 @@ Package warnings after a reload are the dashboard's test suite. Fix all of them:
 - `filters by given "X", which this file does not import, so no control is shown for it`: the trap
   under "Importing a given is what makes it bindable", which the lint now names for you, with the file
   to fix.
-- A tile that does not resolve to a real view, or a non-positive `dashboard_columns`.
+- A tile that does not resolve to a real view; a non-positive `# dashboard { columns }`; a tile view's
+  `# colspan` that is not a positive integer or is wider than the grid; and any property inside the
+  artifact tag Publisher does not read, `dashboard_columns=` included.
 
 Findings carry a `severity`, but `warn` is the ordinary default and tells you nothing about how bad
 one is. Read the text, not the severity and not the count. One message is worth recognising because
@@ -401,9 +466,8 @@ the warning list.
 - Each control renders as the widget you intended (a select shows options; a slider is a slider),
   and changing one changes the numbers.
 - If you added a `# drill`, you clicked it and landed where you meant to, with the given seeded.
-- On a single-query dashboard, every card and tile carries a colspan, each row's colspans sum to
-  `columns`, and the rows end flush with each other. On a composite, the tiles fill the row rather
-  than leaving a gap. Nothing is clipped, no tile is thousands of pixels tall, and no legend or card
+- Every card and tile carries a colspan, each row's colspans sum to `columns`, and the rows end flush
+  with each other. Nothing is clipped, no tile is thousands of pixels tall, and no legend or card
   label ends in `…`.
 
 ## Reference

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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 Copyright (c) Credible Data Inc.
@@ -160,7 +160,7 @@ The user will:
 - **Remove** fields they don't need.
 - **Change** priorities.
 
-Once the definitions are confirmed, write them into the `.malloy` model (see your modeling workflow). Use `#(doc)` annotations to document sources and fields, and `#(filter)` annotations to declare server-side filterable dimensions where appropriate. Keep the confirmed definitions in the conversation; there is no separate plan-file store.
+Once the definitions are confirmed, write them into the `.malloy` model (see your modeling workflow). Use `#(doc)` annotations to document sources and fields, and `given:` parameters to declare runtime-filterable dimensions where appropriate. `#(filter)` is deprecated in favour of native Malloy `given:` parameters. Do not add new `#(filter)` annotations; the two exceptions are `required` and `implicit`, which `given:` cannot cover yet. See `skill:malloy-model` § Legacy: Parameterizable Filters. Keep the confirmed definitions in the conversation; there is no separate plan-file store.
 
 ## Data-driven proposals
 

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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 Copyright (c) Credible Data Inc.
@@ -15,7 +15,7 @@ Add `#(doc)` tags to describe sources and fields in plain language so they are e
 | Tag | Purpose | Goes on |
 |-----|---------|---------|
 | `#(doc)` | Plain-language description for natural-language search | source, dimension, measure, view, join |
-| `#(filter)` | Declare a parameterizable filter (runtime/modeling concern, see `malloy-model`) | source |
+| `#(filter)` | Deprecated, prefer `given:`. Parameterizable filter (runtime/modeling concern, see `malloy-model`) | source |
 
 `#(doc)` is a standard Malloy annotation. It documents a field or source with a human-readable description that downstream tools can surface and search against.
 
@@ -76,9 +76,11 @@ These are governed models: a threshold nobody confirmed is an assumption, and an
 
 Do not hedge measured facts: `avg_energy is avg(energy)` needs no caveat. Hedge only where a domain expert could reasonably choose differently.
 
-## #(filter): see `malloy-model`
+## #(filter): deprecated, see `malloy-model`
 
-`#(filter)` is also a `#(...)`-shaped annotation, but unlike `#(doc)` it's a **runtime/modeling construct**: it shapes governance, query latency, and correctness, not discoverability. The full reference (syntax, filter types, `required` / `implicit` flags, and when each applies) lives in `malloy-model` § Parameterizable Filters with `#(filter)` alongside the other source-authoring constructs.
+`#(filter)` is deprecated in favour of native Malloy `given:` parameters. Do not add new `#(filter)` annotations; the two exceptions are `required` and `implicit`, which `given:` cannot cover yet. See `skill:malloy-model` § Legacy: Parameterizable Filters.
+
+`#(filter)` is also a `#(...)`-shaped annotation, but unlike `#(doc)` it's a **runtime/modeling construct**: it shapes governance, query latency, and correctness, not discoverability. The full reference (syntax, filter types, `required` / `implicit` flags, and when each applies) lives in `malloy-model` § Legacy: Parameterizable Filters alongside the other source-authoring constructs, next to the `given:` guidance that replaces it.
 
 One rule worth knowing here: filters live on the source, never on the consumer. Ad-hoc reports and notebooks that import a source inherit its filters automatically; they do not (and cannot) declare new ones.
 

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 malloy_getContext, and running a first grounded query.
-version: 0.1.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 Copyright (c) Credible Data Inc.

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

@@ -1,7 +1,7 @@
 ---
 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.9
+version: 0.1.10
 ---
 <!--
 Copyright (c) Credible Data Inc.

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.9
+version: 0.1.10
 ---
 <!--
 Copyright (c) Credible Data Inc.
@@ -169,9 +169,21 @@ source: customer_health is customers extend {
 | **Dimensions** | Intrinsic to this table only | Cross-source (require joins) |
 | **Measures** | Single-table aggregations | Cross-source aggregations |
 | **Joins** | None (or only lookup joins intrinsic to the source) | Defines relationships between base sources |
-| **Views** | None (views belong in analysis) | None |
+| **Views** | None, in schema-first (see below) | None, in schema-first (see below) |
 | **One per** | Physical table or computed source | Analytical domain |
 
+**The "no views" rule is schema-first only.** A schema-first model is built before anyone
+has asked a question, so any view in it is a guess. It does **not** apply to the
+analysis-first workflow (`skill:malloy-model-as-you-go`), where every view is a
+question that was asked and verified - there, **saving a view or a dashboard is the right
+call**, in the model file next to the measures it uses. Analysis-first still models
+everything else properly: documented dimensions, measures, and joins.
+
+**Two more rules here are schema-first only.** Analysis-first should skip access modifiers
+and curation - there is no discovery surface to curate when every field was paid for by a
+question - and skip one-file-per-table, keeping a single domain file until it genuinely
+gets unwieldy.
+
 ## Key Rules
 
 - **Every `dimension:` needs `name is expr`**: a bare `dimension: species` is a parse error. Raw columns are queryable directly in `group_by` / `select`; only declare a `dimension:` to derive or rename a field.

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

@@ -0,0 +1,306 @@
+---
+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.10
+---
+
+<!--
+Copyright (c) Credible Data Inc.
+SPDX-License-Identifier: MIT
+-->
+
+# Model as you go
+
+An analysis that lives in a chat transcript is not reproducible. The numbers were right, and
+six weeks later nobody can say what "revenue" excluded, which of four timestamps was the order
+date, or whether the last period was complete. The work is unauditable, so it gets redone.
+
+The fix is to write the assumptions down while the query is still in front of you, in the
+most durable place your session can write. Answer the question, codify what the answer
+assumed, answer the next one. After a handful of questions there is a model, or a notebook,
+where every definition exists because a real question needed it, and every judgment call is
+on the record.
+
+This skill is the codify step. `skill:malloy-analysis` answers the question; this skill
+decides what to write down afterwards, and where.
+
+> **Tool names** are bare here - `get_context`, `execute_query`, `search_database_schema`. The
+> exact prefixed name depends on the host; match against the tools you actually have.
+
+## The loop
+
+```
+QUESTION → ANSWER → CODIFY  ⟲
+              ↑___________|
+```
+
+**The user gets a real answer on question one.** If three tool calls have gone by without
+producing an insight they can read, you have drifted into modelling for its own sake. Stop and
+answer something.
+
+## 1. Answer the question, with `skill:malloy-analysis`
+
+This skill starts when someone asks a data question. **That question is the unit of work, and
+it is theirs.** Do not widen it into a modelling project, and do not swap it for a more
+interesting one you found on the way.
+
+**A broad ask is still an ask.** "Analyse the sales data" is a question whose subject is given
+and whose metric is not. Pick the most obvious question about that subject, say in one line
+which one you picked, and answer it. Never open with a row-count table and a menu of
+"analytical domains"; the menu is worth less than the first real answer would have been.
+
+Load `skill:malloy-analysis` and follow it: discover the model, construct the query, run it,
+verify it, present it. Two of its rules matter most here:
+
+- **Every number you present comes out of a query.** Adding up the rows of a `limit: 15` table
+  by hand drops everything below the cut, and nobody can re-run it.
+- **Your first result is a draft.** Work `skill:malloy-analysis-pitfalls` before presenting.
+
+### Name the decisions the answer rests on
+
+**This is what makes the analysis auditable, and it is the step most easily skipped.**
+
+Almost every query needs at least one judgment call the data cannot settle. Which of four
+timestamps is "the order date". Whether returns count as revenue. Whether to count lines or
+orders. Whether a partial final period belongs in a trend.
+
+A judgment call made silently becomes a hidden assumption. It will be wrong for someone
+eventually, and by then nobody remembers it was a choice rather than a fact. So make the call,
+run with it, and **say what you chose and what you rejected**, with the other number attached
+whenever it is cheap to get:
+
+> Revenue here excludes cancelled **and** returned orders - that's $8.10M. Counting returns as
+> revenue and netting them separately gives $9.18M. I went with the stricter one; say if your
+> reporting does it the other way.
+
+Not every choice rises to this. Raise it when **any** of these holds:
+
+| Raise it when | Because |
+|---|---|
+| The alternative changes the number materially | The user would answer differently depending on which they meant |
+| You are about to codify it | It stops being your choice and becomes everyone's definition |
+| A reasonable analyst would pick the other one | It is a convention, not a fact |
+
+Otherwise state it in a clause and move on. **Asking about everything is as bad as asking about
+nothing**; it turns the loop into a form and trains the reader to skim past it. And **give the
+number under each option, not an abstract question**: "$8.10M excluding them, $9.18M
+including" lets the user answer in one word.
+
+## 2. When there is no model yet
+
+If the tables have no model, define only enough to run the first query. One line is normal:
+
+```malloy
+source: order_items is my_conn.table('ecommerce.order_items')
+```
+
+**Read the columns with `run: source -> { select: * limit: 3 }`.** Prefer it to a schema
+listing: it returns the columns *and* real values, and the values are what catch the surprises
+a column list hides - a date stored as a string, a `total` that excludes tax, a metric column
+that is null on every row.
+
+If a schema tool returns something you cannot explain (no columns, or no tables for a filter
+you can see matches), that is a bug in the tool. Report it. Do not write the workaround into
+your model or your notes as though it were a property of the data.
+
+No `primary_key:`, no dimensions, no measures, no joins, **not yet**. Those arrive in CODIFY,
+each one paid for by a question that needed it. Adding fields because the table has them is the
+habit this skill exists to break.
+
+Add a join only when *this* question cannot be answered without it, then verify its cardinality
+before trusting any aggregate (`group_by: fk, aggregate: n is count(), having: n > 1`).
+
+If a model already exists, ground yourself in it with `get_context` and reuse what is there.
+
+## 3. CODIFY: write the answer's assumptions down
+
+Run this after *every* answered question, while the query is still in front of you. Skipping it
+is how a session ends with a transcript and nothing else.
+
+### Where it goes depends on what you can write
+
+The same assumption lands in a different place depending on the session. Pick the **highest
+rung your tools allow**, and never skip codifying because the top rung is out of reach.
+
+| You can | Codify as | Who inherits it |
+|---|---|---|
+| **Edit the model files** (a local package, a draft package, a compile or reload tool) | A `dimension:`, `measure:`, `join_*:`, or `view:` with a `#(doc)`, in the `.malloy` file | Everyone who queries the model. **Confirm binding decisions first** (below) |
+| **Author notebooks or reports, but not the model** (a viewer of a published package) | In the notebook: `source: orders_q is orders extend { measure: ... }` with the `#(doc)` above it, plus a markdown cell stating the assumption. A question worth re-asking becomes a cell | Readers of the report. State the decision in the cell, and say which definitions the model should adopt |
+| **Only answer in chat** (no file or report tools) | The assumption stated in the answer, plus the Malloy snippet a modeler could paste: the `measure:` with its `#(doc)` | Nobody, until someone acts on it. That is why the snippet matters |
+
+Tell the rungs apart by the tools you have, not by guessing at the user's role: a file-write or
+compile tool means the top rung; a report or notebook tool without model edits means the middle
+one; neither means the bottom.
+
+### What to codify
+
+Look at the query you just ran. For each dimension, measure, join, filter, **and for the shape
+of the query itself**, ask **in this order**:
+
+| Codify it when | Example |
+|---|---|
+| **A reader needs it to trust the number** | the cancelled/returned exclusion - without it every revenue figure reads high |
+| **It encodes a business rule** | a regex parsing a messy column, a status mapping, tier cutoffs |
+| **Another question would reuse it** | `revenue is sum(sale_price)` - everything about orders needs it |
+| **It was hard to get right** | a window function, a multi-step derivation, a verified join |
+
+The first row is the one that matters. A definition is worth keeping less because it saves
+typing than because it stops the next reader misreading the number.
+
+**Codify thin, and leave the ad-hoc behind**: filters tied to one finding, calculations that
+answered exactly one question. A question that needed one measure codifies one measure, not the
+neighbouring columns as well. An empty CODIFY is a fine outcome; say so and move on.
+
+**Then say what you did**, in one line, every time:
+
+> Codified: `revenue is sum(sale_price)` excluding cancelled and returned, `category` via the
+> products join. Left ad-hoc: the `where: created_at > @2023` - just this question's window.
+
+That line shows the model growing and gives the reader a place to object. Never codify
+silently.
+
+### A decision becomes binding the moment it enters the model
+
+While a judgment call lives in one ad-hoc query it is yours, and stating it is enough. Once it
+is in the model file it is the definition everyone inherits, and nobody downstream sees the
+reasoning. So on the top rung, **stop, ask, and wait for an answer** before writing it down.
+Reporting it afterwards ("I used the midpoint, say if you'd rather have the floor") is not
+confirming it; by then it is already the default. On the middle rung, confirm when the report
+will be shared; a private notebook is still yours.
+
+This is not only about measures. Confirm anything that changes what later questions return:
+
+| Confirm before codifying | Because it silently sets |
+|---|---|
+| A source-level `where:` | the scope of *every* later question against that source |
+| A `measure:` definition | the default value of that metric for everyone |
+| A `dimension:` that buckets, maps, or parses | which rows land in which group |
+| A `join_one:`/`join_many:` and its grain | whether aggregates fan out |
+| A saved `view:` | the shape people will re-run and cite |
+
+Ask with the numbers attached:
+
+> I want to make `net_revenue` exclude cancelled and returned. That makes it the default revenue
+> number for every later question - $8.10M rather than $10.81M gross. Good, or does your
+> reporting treat returns differently?
+
+**One confirmation per decision, not per question.** Once the user has settled how revenue
+treats returns, it is settled: reuse it and stop asking. And if the user has told you to stop
+checking in, believe them; state each decision in a clause and keep going.
+
+### Write it down twice
+
+**In the model (or the notebook), as a `#(doc)` on the definition.** This is the part that
+survives. Use `#(doc)`, never a `//` comment, for anything a consumer needs: `#(doc)` is
+machine-readable, so it renders in the UI and retrieval tools read it, while a `//` comment
+reaches nobody but whoever opens the file. Keep `//` for maintainer-only notes. Tag formats on
+the definition too: bare `# currency` on the measure, any scale (`# currency=usd0m`) only in
+views.
+
+```malloy
+#(doc) Order line items joined to products. Grain is one row per line, not per order.
+source: order_items is my_conn.table('ecommerce.order_items') extend {
+  join_one: products is my_conn.table('ecommerce.products') on product_id = products.id
+
+  dimension:
+    #(doc) Canonical order date. Data runs 2019-01-05 to 2026-03-14, so the final year is PARTIAL - never present it as a full period.
+    order_date is created_at::date
+
+  measure:
+    #(doc) Revenue in USD, excluding cancelled and returned orders. Those are 25% of gross, so excluding them is not optional.
+    # currency
+    net_revenue is sum(sale_price) { where: status != 'Cancelled' and status != 'Returned' }
+
+  #(doc) Monthly revenue trend. The question asked on 2026-03-02.
+  # line_chart
+  view: revenue_trend is {
+    group_by: order_month is order_date.month
+    aggregate:
+      # currency=usd0m
+      net_revenue
+    order_by: order_month
+  }
+}
+```
+
+One file per analytical domain, named for it: `order_revenue.malloy`, not `model.malloy`. It
+grows monotonically across the session.
+
+**In a notes file, as the reasoning.** Keep an `analysis-notes.md` beside the model (or a
+markdown cell in the notebook) recording each question, what it found, what got codified and
+what was left ad-hoc, and every verification finding. The model carries the *what*; the notes
+carry the *why* and the evidence. It is also what lets you resume after losing context.
+
+### Save the view when a question is worth re-asking
+
+A saved `view:` turns "we answered that once" into "re-run it". A trend wanted again next
+month belongs in the file as a `view:` with its chart tag (`skill:malloy-charts`); views wanted
+side by side belong in a notebook (`skill:malloy-notebooks`), or in a dashboard surface if your
+host has one. A genuine one-off does not.
+
+> **This departs from `skill:malloy-model` on purpose.** Its "no views in source files" rule
+> assumes a schema-first model, written before anyone asked a question, so its views would be
+> guesses. Here every view is a question that was asked and verified. Two more of its rules do
+> not apply either: skip access modifiers and curation (there is no discovery surface to curate
+> when every field was paid for by a question), and keep one domain file rather than one file
+> per table until it genuinely gets unwieldy. Everything else in `skill:malloy-model` applies:
+> `#(doc)` on every field, verified join cardinality, `nullif` on division, a `given:` for a
+> runtime parameter.
+
+### Then loop
+
+Go back to the question, and let what you just found sharpen the next one:
+
+> Revenue is concentrated in three categories. Worth asking whether that's new - want the same
+> cut by year?
+
+## When the analysis is going to be shared
+
+Docs are not on this list; they happen in CODIFY, as you go. When the user wants to hand it
+over:
+
+1. **Names.** Rename anything whose name only made sense inside one question.
+2. **Doc pass.** Re-read the `#(doc)` lines for anything that drifted as the model grew. Check
+   grain, units, and null handling are each stated somewhere.
+3. **Re-verify.** Re-run the session's key queries against the finished sources. If a number
+   moved, something was codified wrong. This is the check that proves reproducibility; do not
+   skip it.
+4. **Structure**, only if one file has genuinely become unwieldy: base sources per table plus a
+   joined source per domain, per `skill:malloy-model`. Being shared is not itself a reason.
+
+## When to do something else
+
+| Situation | Go to |
+|---|---|
+| Porting prior art (LookML, dbt, a metrics doc): the definitions exist and are agreed, the job is translation | `skill:malloy-lookml-review`, then `skill:malloy-model` |
+| The user names the sources they want built outright, before any question | `skill:malloy-model` |
+| A model already exists, the question rests on no judgment call, and nothing is worth keeping | `skill:malloy-analysis` alone |
+| Open-ended exploration with no intent to keep anything | `skill:malloy-analyze` |
+
+## Anti-patterns
+
+```
+WRONG  Turn "what's our default rate?" into a modelling project
+RIGHT  Answer it, then codify what the answer assumed
+
+WRONG  Propose every dimension and measure for each table in scope
+RIGHT  Codify the two fields this question actually needed
+
+WRONG  Quietly pick one of four timestamps as "the order date"
+RIGHT  "Using created_at; shipped_at would drop 38% as nulls. OK?"
+
+WRONG  Skip codifying because you cannot edit the model
+RIGHT  Put the extend and its #(doc) in the notebook, or hand over the snippet
+
+WRONG  Codify the source-level where:, then mention it in the write-up
+RIGHT  Stop and confirm it; it scopes every question anyone asks later
+
+WRONG  The assumption lives in the chat transcript, or in a // comment
+RIGHT  #(doc) on the definition for what a consumer needs, plus a line in the notes
+
+WRONG  Leave the answered question as a transcript table and move on
+RIGHT  Save it as a view; a question worth answering is usually worth re-asking
+
+WRONG  Curate access modifiers and split one file per table to "do it properly"
+RIGHT  Skip both; they solve a schema-first problem this model does not have
+```

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.9
+version: 0.1.10
 ---
 <!--
 Copyright (c) Credible Data Inc.
@@ -96,9 +96,8 @@ Publishing is out of scope for open-source v1. Self-hosters move a finished mode
 
 **Two paths to a model: both produce the same fully documented result:**
 - **Schema-first:** "Model my data" → 8-step workflow above using the relevant skills
-- **Analysis-first:** "Explore this data" → `skill:malloy-analyze` → formalize via `skill:malloy-model` (`reference/analysis-to-model.md`)
-
-After analysis completes, **always recommend formalizing into a model.**
+- **Analysis-first:** a data question arrives before any model exists → `skill:malloy-model-as-you-go`. It answers the question with `skill:malloy-analysis`, then codifies what the answer assumed into the model, one question at a time, confirming binding decisions first. The model exists by the end; there is no separate formalize step.
+- **Open-ended exploration** with no intent to keep anything: `skill:malloy-analyze`. If it turns into something worth keeping, formalize via `skill:malloy-model` (`reference/analysis-to-model.md`).
 
 ## Agent Behavior
 
@@ -120,9 +119,9 @@ After analysis completes, **always recommend formalizing into a model.**
 | "Model from LookML" | 8-step with prior art via `skill:malloy-lookml-review` |
 | "Explore this data", "what's interesting?", "show me the top X" | `skill:malloy-analyze` (EDA) |
 | "Build a dashboard", "create views" on existing model | `skill:malloy-analyze` (views), plus `skill:malloy-charts` or `skill:malloy-notebooks` as needed |
-| "Build a model but not sure what metrics" | `skill:malloy-analyze` first, then formalize via `skill:malloy-model` |
+| "Build a model but not sure what metrics" | `skill:malloy-model-as-you-go`: answer their first real question, codify what it assumed, repeat |
 
-**If the user's first message is a data question** (not "build me a model"), route to `skill:malloy-analyze`. After analysis completes, **always recommend formalizing via the analysis-to-model workflow** (`skill:malloy-model` → `reference/analysis-to-model.md`).
+**If the user's first message is a data question** (not "build me a model"), route to `skill:malloy-model-as-you-go`. It answers with `skill:malloy-analysis` and grows the model from what each answer assumed, so there is nothing to formalize afterwards.
 
 ## Additional Support Skills
 

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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 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.9
+version: 0.1.10
 ---
 <!--
 Copyright (c) Credible Data Inc.