[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69A1PZMYACDCEWDXQZ9YCQR":3,"skill-same:01M69A1PZMYACDCEWDXQZ9YCQR":49},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":21,"linkOnly":22,"markdownContent":23,"markdownBody":24,"frontMatter":25,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M69A1PZMYACDCEWDXQZ9YCQR","schema-query",null,"Ground DAX work in the cached semantic-model catalog, shipped measures, relationships, and explicit filter values.","microsoft\u002Ffabric-apps-analytic-templates","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69A1FS1CN0V6AX6B3TKVA5N",29,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffabric-apps-analytic-templates\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fschema-query\u002FSKILL.md",[],[19,20],"schema query","dax","2026-11-10 10:12:30",false,"---\nname: schema-query\ndescription: Ground DAX work in the cached semantic-model catalog, shipped measures, relationships, and explicit filter values.\n---\n\n# Grounding semantic-model work\n\n**Prerequisite:** register the task's semantic model as a Rayfin connector first (AGENTS.md\n\"Connector setup\"):\n`npx rayfin connector add --type fabric-semanticmodel --name \u003Cname> --workspace-id \u003CworkspaceId> --item-id \u003CitemId>`.\nUntil then `query-schema` has no model to catalog and exits with that command.\n\nThe semantic model's own catalog is cached as a local SQLite database and queried with SQL:\n\n```bash\nnpx fabric-app-semantic-model-tools query-schema \"SELECT [Name], [Expression] FROM info_view_measures WHERE [Table] = 'Sales'\"\n```\n\nQuote identifiers in inline SQL with SQLite brackets (`[Table]`, `[Max Length]`), which pass\nunchanged through both bash and PowerShell. Inline SQL is fine for model identifiers and literals\nquoted as `[...]` \u002F `'...'` (double any `'` inside a literal), including LIKE patterns with `%`,\neven when they came from earlier catalog output. Put the SQL in a `.sql` file and pass\n`--file \u003Cfile.sql>` only when a name or value contains `\"`, `` ` ``, `$`, `\\`, or a newline, or\nwhen it embeds free-form text from the user. In a LIKE pattern, don't write a whole environment\nvariable name between two `%` signs (e.g. `%PATH%`, `%DATE%`); use\n`instr(lower([Name]), 'path') > 0` instead.\n\n`--search` and `--sql` are repeatable and run in one process, so ask everything you already know\nyou need in one command rather than one command per question:\n\n```bash\nnpx fabric-app-semantic-model-tools query-schema --search \"revenue margin\" --sql \"SELECT [Name], [Expression] FROM info_view_measures WHERE [Table] = 'Sales'\" --sql \"SELECT [Name], [DataType] FROM info_view_columns WHERE [Table] = 'Sales'\"\n```\n\nEach invocation costs a full model round trip, and a round trip re-sends the whole conversation, so\nthree separate commands cost roughly three times what one batch does. Batch the questions you can\nwrite down now; keep a question whose *content* depends on an earlier answer for the next command.\nUp to 8 statements per invocation.\n\nThe whole batch shares one result-size budget — the same one a single statement gets — divided\nbetween the statements, with each statement's unused share rolling forward to the next. So batch\n**focused** statements. A statement that returns a lot is truncated to its own share; later\nstatements keep their share of the budget. Run a query you expect to return a lot in its own\ncommand so it gets the whole budget.\n\nEach statement's result is labelled with the query that produced it, searches first, then SQL. A\nstatement that fails stays in the output beside the ones that succeeded. The exit code is the worst\noutcome across the batch: 1 if any statement failed, 2 if any was truncated, 0 otherwise.\n\nThe database builds itself on first use and rebuilds when stale, so ask a question rather than\nrefreshing it by hand. `.schema\u002Fmodels\u002F\u003CitemId>\u002Fcatalog.md` names every table, its real row and\ncolumn counts, and how the tables join; read it once and the rest is ordinary SQL.\n\nThe tables hold the untouched output of `INFO.VIEW.TABLES()`, `INFO.VIEW.COLUMNS()`,\n`INFO.VIEW.MEASURES()`, `INFO.VIEW.RELATIONSHIPS()` and `COLUMNSTATISTICS()`, under the model's own\ncolumn names. Nothing is renamed, flattened, or summarized, so a column you see in the catalog is a\ncolumn DAX returned.\n\nBesides metadata, the catalog stores the `COLUMNSTATISTICS()` output, including each column's\n`Min`\u002F`Max` sample values. It lives locally under `.schema\u002Fmodels\u002F`, which is git-ignored and\nrebuilt on demand; SQL queries read only that local copy.\n\nDo not hand-run exploratory `INFO.*` queries, read the catalog database directly, bypass the catalog\nwith connector probes, or ask the user for metadata the catalog can answer.\n\n## Querying\n\nEvery query starts with result metadata including `totalRows`, `returnedRows`, and `truncated`.\nZero rows is a successful answer, not an error; it means the model has no such entity.\n\nResults are capped by row count and by size, so filter in SQL instead of selecting whole tables and\nreading the overflow. **A result with `truncated: true` is incomplete and cannot be used to choose\nmodel objects or author DAX.** The command exits with code 2 after printing the bounded preview.\nNarrow the `WHERE` clause and\u002For projection and rerun until the entities needed by the plan appear\nin a result with `truncated: false`. `SELECT *` on `info_view_measures` will truncate on a large\nmodel; selecting only the required metadata and filtering by table, name, folder, description, or\nexpression will not.\n\nThe connection is read-only. A failing query comes back as an error message, so a malformed query\ncosts one retry, not a corrupted cache.\n\n## Column statistics\n\n`column_statistics` carries `Min`, `Max`, `Cardinality` and `Max Length` for each column. Use them\nto choose grouping columns, bound date and numeric filters, and anticipate result size.\n\nThey are not a substitute for the model's logic. When a shipped measure computes the same quantity,\nuse the measure: a statistic is the raw column extent, ignoring filter context, relationships, and\nany business rule the measure encodes. A column whose cardinality happens to match an expected row\ncount is not evidence that reading it is correct.\n\nIf `column_statistics` is missing from the catalog, the model did not return statistics. Continue\nwithout them.\n\n## Global semantic discovery\n\nSearch the whole catalog before restricting discovery to a domain-looking table prefix. Helper,\nparameter, selector, calculation, and metadata tables may have names that do not share the user's\nterm or the primary fact-table prefix. Search table names and descriptions, measure names,\ndescriptions, expressions, and display folders, and column names and descriptions in one query.\nStart with the ranked catalog-wide search, replacing the terms with the user's concepts:\n\n```bash\nnpx fabric-app-semantic-model-tools query-schema --search \"requested concept comparison\"\n```\n\nEvery search token must appear somewhere in an entity's name, parent table, description, display\nfolder, expression, or type. Exact and prefix name matches rank above descriptive or expression\nmatches, and shipped measures rank above columns at the same lexical relevance. After the global\nresult identifies candidate tables, run a focused, untruncated SQL query for their measures,\ncolumns, descriptions, and expressions. Do not begin with a domain-prefix restriction: that can\nhide a helper, parameter, selector, or measure owned elsewhere.\n\nSearch is a findability surface, not a reading surface. Ranking sees every field in full, but the\nprinted rows omit a `description` that is identical across the model and shorten a long\n`expression` to its head plus its length. The result's `trimmed` counts say when either happened.\nBoth fields are still matched, so nothing becomes unfindable — `SELECT` the row when you need the\nfull text. Do not treat a shortened expression as the measure's definition.\n\n## Model-facing workflow\n\n1. Read `catalog.md` once when orientation is needed. Do not fetch it again in the same task.\n2. Run global semantic discovery across tables, measures, and columns before applying a\n   domain-specific table-name restriction.\n3. Start with shipped measures. Whenever a table becomes part of the plan, inspect measures owned\n   by that table before authoring DAX. Query all selected tables in one statement using `IN` or\n   `OR`, returning at least `[Table]`, `[Name]`, `[Expression]`, `[Description]`,\n   `[FormatString]`, and `[DisplayFolder]`. Never reconstruct business logic from columns when the\n   model already ships the measure. A single-table query on `info_view_tables` (no JOIN, comma\n   join, or UNION) automatically includes bounded `ownedMeasures` for each returned table; review\n   those before choosing physical columns.\n4. Answer several known metadata questions in one command. Combine them into one statement with a\n   join or an `OR` where they share a shape; where they do not, pass them as repeated `--sql`\n   (and `--search`) flags in a single invocation. Either way it is one round trip. One command per\n   question is the single most expensive habit in discovery.\n5. Take explicit filter values from the request, and bind every other qualifier in it to a filter\n   too. A qualifier can imply a value the request never states: the complement of a named value,\n   one section of a parameter or selector table, a status or flag. Take such values from the model\n   (a parameter table's `[Expression]`, a column's `column_statistics` `[Min]`\u002F`[Max]`), not from\n   guesses. Apart from those statistics the catalog holds no other row values, but a\n   parameter or calculated table (for example a `DATATABLE`) shows its literal rows in\n   `info_view_tables.[Expression]`; read that expression before inventing labels or keys. Do not\n   probe the model for row values during discovery. When a value needs confirmation, add one small\n   value-check query file\n   (for example `EVALUATE FILTER(VALUES('Customer'[Country]), 'Customer'[Country] = \"Canada\")`) to\n   the same final `run-dax-query` call. The value check counts toward that call's four-file limit;\n   when the plan already has four queries, fold the check into one of them or run it in the next\n   call. An empty value-check result is the signal to correct that value once.\n6. Before another schema request, check whether an earlier result already answers the question.\n   Never rerun an identical or equivalent schema query.\n7. Stop discovery only after every requested output field has an exact source mapping; the shipped\n   measures, grouping columns, relationship path, and filter grain are grounded; every explicit\n   filter value is bound to its exact column (its value comes from the request and, if needed, is\n   confirmed by the value check in step 5, not by more discovery); every qualifier in the request\n   is bound to a filter, including implied ones (step 5); and no mapping depends on a truncated\n   result.\n8. Write and validate the DAX with the [dax-authoring](..\u002Fdax-authoring\u002FSKILL.md) skill.\n\n## DAX plan and semantic grain\n\nBefore writing DAX, form a compact plan containing:\n\n- every requested output field;\n- the exact source for each field: a fully qualified grouping\u002Flabel column, an exact shipped\n  measure name for every business value, or an explicit literal;\n- exact filters and values, including the ones the request implies rather than names;\n- relevant relationship path;\n- expected output columns and row shape;\n- unresolved filter candidates, if any.\n\nKeep this plan in your working notes; do not write it to a file. `run-dax-query` does not know the\nplan, so compare the columns, row count, and warnings it reports with the plan yourself.\n\nDo not generate DAX until every requested business value is bound to an exact shipped measure and\nevery label\u002Fgroup is bound to an exact column. If exhaustive, untruncated measure discovery\nestablishes that no suitable measure exists, record both the missing measure and the catalog\nevidence before declaring a different source. Partial measure results are not evidence that a\nmeasure is absent.\n\nA selected table is not fully inspected until its owned measures have been reviewed. This is\nespecially important for helper, parameter, selector, calculation, and metadata tables: their rows\nmay provide labels or filter context while an owned measure returns the requested value. Group by\nthe helper column and evaluate the shipped measure; do not invent one expression per row from\nsimilarly named physical columns. If owned measures do not explain the table's semantic role,\nsearch measure expressions for references to that table before falling back to raw aggregation.\n\nIf a catalog refresh fails, or would drop a view the previous catalog has (for example a throttled\n`INFO.VIEW.MEASURES()`), the previous database is kept rather than replaced by the partial\nbuild, the query is answered from it, and stderr prints a warning naming the catalog's age and\nwhat failed. A refresh that is incomplete only in views the previous catalog also lacked is\npublished with an incomplete-catalog warning. Continue discovery from that cache. Treat the warning\nas a reason to avoid freshness-sensitive assumptions, not as permission to ignore the cached\ncatalog. When no previous catalog exists, a partial build is still used and a warning says which\nviews are missing.\n","# Grounding semantic-model work\n\n**Prerequisite:** register the task's semantic model as a Rayfin connector first (AGENTS.md\n\"Connector setup\"):\n`npx rayfin connector add --type fabric-semanticmodel --name \u003Cname> --workspace-id \u003CworkspaceId> --item-id \u003CitemId>`.\nUntil then `query-schema` has no model to catalog and exits with that command.\n\nThe semantic model's own catalog is cached as a local SQLite database and queried with SQL:\n\n```bash\nnpx fabric-app-semantic-model-tools query-schema \"SELECT [Name], [Expression] FROM info_view_measures WHERE [Table] = 'Sales'\"\n```\n\nQuote identifiers in inline SQL with SQLite brackets (`[Table]`, `[Max Length]`), which pass\nunchanged through both bash and PowerShell. Inline SQL is fine for model identifiers and literals\nquoted as `[...]` \u002F `'...'` (double any `'` inside a literal), including LIKE patterns with `%`,\neven when they came from earlier catalog output. Put the SQL in a `.sql` file and pass\n`--file \u003Cfile.sql>` only when a name or value contains `\"`, `` ` ``, `$`, `\\`, or a newline, or\nwhen it embeds free-form text from the user. In a LIKE pattern, don't write a whole environment\nvariable name between two `%` signs (e.g. `%PATH%`, `%DATE%`); use\n`instr(lower([Name]), 'path') > 0` instead.\n\n`--search` and `--sql` are repeatable and run in one process, so ask everything you already know\nyou need in one command rather than one command per question:\n\n```bash\nnpx fabric-app-semantic-model-tools query-schema --search \"revenue margin\" --sql \"SELECT [Name], [Expression] FROM info_view_measures WHERE [Table] = 'Sales'\" --sql \"SELECT [Name], [DataType] FROM info_view_columns WHERE [Table] = 'Sales'\"\n```\n\nEach invocation costs a full model round trip, and a round trip re-sends the whole conversation, so\nthree separate commands cost roughly three times what one batch does. Batch the questions you can\nwrite down now; keep a question whose *content* depends on an earlier answer for the next command.\nUp to 8 statements per invocation.\n\nThe whole batch shares one result-size budget — the same one a single statement gets — divided\nbetween the statements, with each statement's unused share rolling forward to the next. So batch\n**focused** statements. A statement that returns a lot is truncated to its own share; later\nstatements keep their share of the budget. Run a query you expect to return a lot in its own\ncommand so it gets the whole budget.\n\nEach statement's result is labelled with the query that produced it, searches first, then SQL. A\nstatement that fails stays in the output beside the ones that succeeded. The exit code is the worst\noutcome across the batch: 1 if any statement failed, 2 if any was truncated, 0 otherwise.\n\nThe database builds itself on first use and rebuilds when stale, so ask a question rather than\nrefreshing it by hand. `.schema\u002Fmodels\u002F\u003CitemId>\u002Fcatalog.md` names every table, its real row and\ncolumn counts, and how the tables join; read it once and the rest is ordinary SQL.\n\nThe tables hold the untouched output of `INFO.VIEW.TABLES()`, `INFO.VIEW.COLUMNS()`,\n`INFO.VIEW.MEASURES()`, `INFO.VIEW.RELATIONSHIPS()` and `COLUMNSTATISTICS()`, under the model's own\ncolumn names. Nothing is renamed, flattened, or summarized, so a column you see in the catalog is a\ncolumn DAX returned.\n\nBesides metadata, the catalog stores the `COLUMNSTATISTICS()` output, including each column's\n`Min`\u002F`Max` sample values. It lives locally under `.schema\u002Fmodels\u002F`, which is git-ignored and\nrebuilt on demand; SQL queries read only that local copy.\n\nDo not hand-run exploratory `INFO.*` queries, read the catalog database directly, bypass the catalog\nwith connector probes, or ask the user for metadata the catalog can answer.\n\n## Querying\n\nEvery query starts with result metadata including `totalRows`, `returnedRows`, and `truncated`.\nZero rows is a successful answer, not an error; it means the model has no such entity.\n\nResults are capped by row count and by size, so filter in SQL instead of selecting whole tables and\nreading the overflow. **A result with `truncated: true` is incomplete and cannot be used to choose\nmodel objects or author DAX.** The command exits with code 2 after printing the bounded preview.\nNarrow the `WHERE` clause and\u002For projection and rerun until the entities needed by the plan appear\nin a result with `truncated: false`. `SELECT *` on `info_view_measures` will truncate on a large\nmodel; selecting only the required metadata and filtering by table, name, folder, description, or\nexpression will not.\n\nThe connection is read-only. A failing query comes back as an error message, so a malformed query\ncosts one retry, not a corrupted cache.\n\n## Column statistics\n\n`column_statistics` carries `Min`, `Max`, `Cardinality` and `Max Length` for each column. Use them\nto choose grouping columns, bound date and numeric filters, and anticipate result size.\n\nThey are not a substitute for the model's logic. When a shipped measure computes the same quantity,\nuse the measure: a statistic is the raw column extent, ignoring filter context, relationships, and\nany business rule the measure encodes. A column whose cardinality happens to match an expected row\ncount is not evidence that reading it is correct.\n\nIf `column_statistics` is missing from the catalog, the model did not return statistics. Continue\nwithout them.\n\n## Global semantic discovery\n\nSearch the whole catalog before restricting discovery to a domain-looking table prefix. Helper,\nparameter, selector, calculation, and metadata tables may have names that do not share the user's\nterm or the primary fact-table prefix. Search table names and descriptions, measure names,\ndescriptions, expressions, and display folders, and column names and descriptions in one query.\nStart with the ranked catalog-wide search, replacing the terms with the user's concepts:\n\n```bash\nnpx fabric-app-semantic-model-tools query-schema --search \"requested concept comparison\"\n```\n\nEvery search token must appear somewhere in an entity's name, parent table, description, display\nfolder, expression, or type. Exact and prefix name matches rank above descriptive or expression\nmatches, and shipped measures rank above columns at the same lexical relevance. After the global\nresult identifies candidate tables, run a focused, untruncated SQL query for their measures,\ncolumns, descriptions, and expressions. Do not begin with a domain-prefix restriction: that can\nhide a helper, parameter, selector, or measure owned elsewhere.\n\nSearch is a findability surface, not a reading surface. Ranking sees every field in full, but the\nprinted rows omit a `description` that is identical across the model and shorten a long\n`expression` to its head plus its length. The result's `trimmed` counts say when either happened.\nBoth fields are still matched, so nothing becomes unfindable — `SELECT` the row when you need the\nfull text. Do not treat a shortened expression as the measure's definition.\n\n## Model-facing workflow\n\n1. Read `catalog.md` once when orientation is needed. Do not fetch it again in the same task.\n2. Run global semantic discovery across tables, measures, and columns before applying a\n   domain-specific table-name restriction.\n3. Start with shipped measures. Whenever a table becomes part of the plan, inspect measures owned\n   by that table before authoring DAX. Query all selected tables in one statement using `IN` or\n   `OR`, returning at least `[Table]`, `[Name]`, `[Expression]`, `[Description]`,\n   `[FormatString]`, and `[DisplayFolder]`. Never reconstruct business logic from columns when the\n   model already ships the measure. A single-table query on `info_view_tables` (no JOIN, comma\n   join, or UNION) automatically includes bounded `ownedMeasures` for each returned table; review\n   those before choosing physical columns.\n4. Answer several known metadata questions in one command. Combine them into one statement with a\n   join or an `OR` where they share a shape; where they do not, pass them as repeated `--sql`\n   (and `--search`) flags in a single invocation. Either way it is one round trip. One command per\n   question is the single most expensive habit in discovery.\n5. Take explicit filter values from the request, and bind every other qualifier in it to a filter\n   too. A qualifier can imply a value the request never states: the complement of a named value,\n   one section of a parameter or selector table, a status or flag. Take such values from the model\n   (a parameter table's `[Expression]`, a column's `column_statistics` `[Min]`\u002F`[Max]`), not from\n   guesses. Apart from those statistics the catalog holds no other row values, but a\n   parameter or calculated table (for example a `DATATABLE`) shows its literal rows in\n   `info_view_tables.[Expression]`; read that expression before inventing labels or keys. Do not\n   probe the model for row values during discovery. When a value needs confirmation, add one small\n   value-check query file\n   (for example `EVALUATE FILTER(VALUES('Customer'[Country]), 'Customer'[Country] = \"Canada\")`) to\n   the same final `run-dax-query` call. The value check counts toward that call's four-file limit;\n   when the plan already has four queries, fold the check into one of them or run it in the next\n   call. An empty value-check result is the signal to correct that value once.\n6. Before another schema request, check whether an earlier result already answers the question.\n   Never rerun an identical or equivalent schema query.\n7. Stop discovery only after every requested output field has an exact source mapping; the shipped\n   measures, grouping columns, relationship path, and filter grain are grounded; every explicit\n   filter value is bound to its exact column (its value comes from the request and, if needed, is\n   confirmed by the value check in step 5, not by more discovery); every qualifier in the request\n   is bound to a filter, including implied ones (step 5); and no mapping depends on a truncated\n   result.\n8. Write and validate the DAX with the [dax-authoring](..\u002Fdax-authoring\u002FSKILL.md) skill.\n\n## DAX plan and semantic grain\n\nBefore writing DAX, form a compact plan containing:\n\n- every requested output field;\n- the exact source for each field: a fully qualified grouping\u002Flabel column, an exact shipped\n  measure name for every business value, or an explicit literal;\n- exact filters and values, including the ones the request implies rather than names;\n- relevant relationship path;\n- expected output columns and row shape;\n- unresolved filter candidates, if any.\n\nKeep this plan in your working notes; do not write it to a file. `run-dax-query` does not know the\nplan, so compare the columns, row count, and warnings it reports with the plan yourself.\n\nDo not generate DAX until every requested business value is bound to an exact shipped measure and\nevery label\u002Fgroup is bound to an exact column. If exhaustive, untruncated measure discovery\nestablishes that no suitable measure exists, record both the missing measure and the catalog\nevidence before declaring a different source. Partial measure results are not evidence that a\nmeasure is absent.\n\nA selected table is not fully inspected until its owned measures have been reviewed. This is\nespecially important for helper, parameter, selector, calculation, and metadata tables: their rows\nmay provide labels or filter context while an owned measure returns the requested value. Group by\nthe helper column and evaluate the shipped measure; do not invent one expression per row from\nsimilarly named physical columns. If owned measures do not explain the table's semantic role,\nsearch measure expressions for references to that table before falling back to raw aggregation.\n\nIf a catalog refresh fails, or would drop a view the previous catalog has (for example a throttled\n`INFO.VIEW.MEASURES()`), the previous database is kept rather than replaced by the partial\nbuild, the query is answered from it, and stderr prints a warning naming the catalog's age and\nwhat failed. A refresh that is incomplete only in views the previous catalog also lacked is\npublished with an incomplete-catalog warning. Continue discovery from that cache. Treat the warning\nas a reason to avoid freshness-sensitive assumptions, not as permission to ignore the cached\ncatalog. When no previous catalog exists, a partial build is still used and a warning says which\nviews are missing.\n",{"name":5,"description":7},"main","739f97c24e26b14982e39da3dbd9c4babc9c0071",".agents\u002Fskills\u002Fschema-query",14,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffabric-apps-analytic-templates","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 07:06:01",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add microsoft\u002Ffabric-apps-analytic-templates --skill schema-query",{"tool":41,"command":42},"bunx","bunx skills add microsoft\u002Ffabric-apps-analytic-templates --skill schema-query",{"tool":44,"command":45},"pnpm","pnpm dlx skills add microsoft\u002Ffabric-apps-analytic-templates --skill schema-query","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffabric-apps-analytic-templates\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fschema-query\u002FSKILL.md",true,[],[50,76,93,106,127,140],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":54,"categories":55,"keywords":56,"publishedAt":21},"01M69A1VQP5WSZ66RXSG09KM9H","visuals","Use when user wants to incorporate charts, graphs, KPI cards, data grid, slicers, or other visual representations of data into their project. Use VegaVisual, KpiCard, DataGrid, and built-in slicer components, utilizing the shared DataTable input, formatting, and theme. Covers the VisualContainer chrome charts, KPI cards, and grids get by default, plus named multi-table data input for layered overlays and reference lines.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffabric-apps-analytic-templates\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fvisuals\u002FSKILL.md",[],[52,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75],"for","Charts","theme","shared","components","chrome","get","overlays","project","default","kpi","use","visual","grid","multi","layered","graphs","data","input",{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":21},"01M69A1T4T6N6V7VDQPSJWRMPW","visual-interactivity","Implements visual selections and coordinated visual behavior. Covers Vega-Lite native selections, VegaVisual and DataGrid interaction events, cross-filtering, cross-highlighting, filter-aware grid totals, and parameterized query factories for runtime visual state.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffabric-apps-analytic-templates\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fvisual-interactivity\u002FSKILL.md",[],[83,69,84,70,85,86,87,88,89,90,91,92,57],"visual interactivity","behavior","runtime","filtering","native","query","events","filter","interaction","state",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":104,"publishedAt":21},"01M69A1RD7HV2Q26JNJME154M9","semantic-model-data","How the app reads semantic model data at runtime: useSemanticModelQuery, its normalized result and error shape, error categories and overflow, bounding rows, and the app-level query cache.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffabric-apps-analytic-templates\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsemantic-model-data\u002FSKILL.md",[99],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[105],"semantic model data",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":123,"publishedAt":21},"01M69A1N2GY1T810P5WKHCKTC4","query-design","Separates DAX data-fetching from TypeScript presentation. Guides when to use  DAX vs. TypeScript vs. Vega-Lite for aggregation, total rows, FORMAT(), SELECTCOLUMNS,  BLANK handling, fixed filters, multi-grain queries, and format strings.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffabric-apps-analytic-templates\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fquery-design\u002FSKILL.md",[112,117,120],{"categoryNo":113,"categoryName":114,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":118,"categoryName":119,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":121,"categoryName":122,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000032","设计师",[124,125,20,126],"design","query design","typescript",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":136,"publishedAt":21},"01M69A1KFX4240RA669XAK9QA2","dax-authoring","Write and test DAX queries against Power BI semantic models. Covers DAX syntax rules, query patterns, time intelligence, and an iterative test workflow using `npx fabric-app-semantic-model-tools run-dax-query --dax \u003Cfile> --alias \u003Cname>`.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffabric-apps-analytic-templates\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdax-authoring\u002FSKILL.md",[133],{"categoryNo":134,"categoryName":135,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000008","测试与质量",[137,20,138,139],"dax authoring","workflow","test",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":148,"publishedAt":21},"01M69A1HWMAGX3YTW6VNCVHAJP","app-design","Use when building or modifying the app layout,  creating UI components, or making any visual design decisions.  Ensures consistency, accessibility, and a polished, unique app.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ffabric-apps-analytic-templates\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fapp-design\u002FSKILL.md",[146,147],{"categoryNo":118,"categoryName":119,"taxonomyType":115,"taxonomyTypeDesc":116},{"categoryNo":121,"categoryName":122,"taxonomyType":102,"taxonomyTypeDesc":103},[149,124,150,61,151,152,153,68,154,69,155,156,157],"app design","app","accessibility","consistency","ui components","decisions","visual design","layout","ui"]