القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
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.
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.
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.
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.
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.
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.
استنادا إلى تصنيف SOC المهني
| 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. |
Publisher.embed(selector, { src })drops a package page into a host page as a sandboxed, auto-resizing iframe. Same-origin embeds authenticate with the browser's cookies; cross-origin embeds need a signed token.
<script src="https://your-publisher/sdk/publisher.js"></script>
<div id="dashboard"></div>
<script>
const handle = Publisher.embed("#dashboard", {
src: "https://your-publisher/environments/demo/packages/sales/index.html",
});
// handle.destroy() removes the iframe and detaches its listeners.
</script>
embed(selector, options) returns { iframe, destroy() }. Options: src (required), token (a signed token for cross-origin auth, appended as embed_token), height (omit to auto-size; a number is treated as pixels), and allow (the iframe permissions policy).
Omit height and the frame auto-sizes. The embedded page measures its real content height and posts a publisher:resize message to the host, which resizes the iframe and accepts that message only from the iframe it created. You write none of this; it ships in /sdk/publisher.js, so the embedded page only has to load that script.
Do not rely on body { min-height: 100vh } to drive the frame height. The runtime deliberately measures the content's bottom edge, not the viewport, to avoid a grow-forever loop.
options.token. The runtime appends it to the iframe URL as embed_token; the embedded page must read it (from location.search) and call Publisher.setToken(token). Because it rides in the URL, it can land in browser history, Referer headers, and server logs, so keep it short-lived and scoped to that one embed, and never put a long-lived or admin token in client HTML.allow-scripts allow-same-origin allow-forms). Design for that: no top-level navigation, no popups.public/ as strictly first-party code: do not load untrusted third-party scripts, and do not move query results off to other hosts. Tighter per-embed isolation is planned.