malloy-define

Propose sources and definitions

This skill covers three consecutive activities when building or extending a Malloy semantic model:

Tool names are written bare here - get_context, execute_query, search_malloy_docs. The exact prefixed name depends on the host surface; match each against the tools you actually have.

• Propose scope: which tables and which questions the model is for.
• Propose sources: the architectural blueprint (which sources, what grain).
• Propose definitions: the specific fields per base source (renames, dimensions, measures).

Both happen in conversation. Propose, let the user confirm or adjust, then carry the confirmed plan forward into the actual .malloy model. There is no separate plan-file store: keep the source plan and field proposals in the conversation, and write the model itself when the user has confirmed. See your modeling workflow for the broader picture.

Read the existing model first so you propose against what is really there. Use get_context with a plain-English description to inspect the current sources and fields and find the most relevant existing sources. Confirm the scope (below) before proposing the source plan.

Propose the analytical scope

When: after you have read the package's sources and fields and looked at the data distributions. Goal: present what you found, recommend one analytical focus, and let the user pick. Query the data with execute_query for row counts and data-quality problems, and record the proposal and the user's decision in your modeling workflow's modeling-notes.md.

Scope is "which questions", not just "which tables". A model aimed at recommendation looks different from one aimed at catalog analysis over the same tables. A single A/B/C question about table inclusion is the source-plan question asked too early.

Present four things:

1. A table summary with rows, columns, role and key relationships. Roles: Fact (events you measure: orders, sessions), Dimension (entities you slice by: customers, products), Bridge (many-to-many links: order_items, tags), Operational (ETL, staging, audit; not analytical).
2. 2-3 analytical focuses, each with the tables it covers (for example "Order Analysis: revenue, trends, product performance"), and one recommendation with reasons. Say what kind of model this is and what that rules out. A dataset of events supports trends over time. A dataset of entities with cumulative counters cannot do period-over-period analysis however well it is built ("release dates are 98% null, so this model cannot do calendar analysis"). The user should learn what the model will never answer before choosing.
3. Tables to skip, with reasons: operational tables, staging copies of a table you model, and pre-aggregated summaries (compute fresh in Malloy; a pre-aggregated source ignores your filters, see skill:malloy-gotchas-modeling).
4. Options the user can answer in one word. If your host has an ask_user tool, put the options in that card and nowhere else, with the evidence and your recommendation as prose. Otherwise give lettered one-line options (label, tables, key questions), mark the recommended one, and invite a mix ("A plus suppliers").